FileMaker Clipboard Bugs — verified, with reproducible test files

Published by ai2fm · companion to the v2.5 release · last updated 2026-08-22

During the R&D for ai2fm v2.5 we found, documented and reported to Claris International Inc. a set of bugs in FileMaker’s clipboard serialisation. This page is the account of each one — but unlike a changelog, every claim here is backed by files you can download and reproduce yourself.

For each bug we ship a folder containing the FileMaker file itself plus real captures:

• <Step>_<year>.fmp12 — the actual FileMaker file, one per version, so you can open the exact step we tested and copy it yourself.
• <Step>_Source_<year>.xml — the exact clipboard FileMaker produced when we copied that step.
• <Step>_Result_<year>.fmscript — what ai2fm made of that clipboard.
• where a recovery exists, the corrected files that prove the fix round-trips.

Open the file, copy the same step in your own FileMaker, and you will get the same clipboard. That is the point: nothing here asks for your trust.

Download the test suite

⬇ Bugs_Test_Suite.zip — 5.9 MB, every file referenced on this page.

All eighteen bug folders, the FileMaker files, the clipboard captures and the .fmscript results. Unzip it and the paths in each bug below are exactly the paths you will have on disk. Where a bug was tested on both platforms the folder has WIN/ and MAC/ subfolders; where we filed a report with Claris, the files we sent them are in Submitted_to_Claris/.

The FileMaker files open in FileMaker Pro 2025 or 2026 as their names say. Nothing in the suite connects to a server or needs a licence — they are ordinary files holding the script steps described here.

First, the good news: your files are safe

These are serialisation bugs, not data-destruction bugs. The values are intact in your .fmp12. What breaks is the clipboard — the XML FileMaker writes when you copy a script step, and reads when you paste one. Nothing on this page has corrupted your solution on disk. You only meet these bugs when you copy a step and move it somewhere — which is exactly what ai2fm does, and why we found them.

Status after FileMaker Pro 26.0.3 (Bugs 1–8, 16 and 17 re-verified)

FileMaker Pro 26.0.3 (September 2026) lists two clipboard fixes in its release notes: Configure AI Account copied from FileMaker 2025 and pasted into 2026, and Print PDF losing its page setup on copy and paste. We re-captured Bugs 1–8 on 26.0.3, on Windows, on 2026-09-24, and re-checked Bugs 16 and 17 later.

FileMaker 2025 is not being updated, so the direction from 2026 into 2025 stays broken for Bug 2. Bug 3 is broken in both directions. ai2fm’s Target FileMaker Version setting writes whichever form the destination needs, in both directions.

Bug 10 and Bug 11 are not something an update can fix. In FileMaker 2026 the ODBC user name and password are calculations: a literal name is written in quotes, "Admin", and an unquoted Get ( AccountName ) is evaluated when the step runs. FileMaker 2025 and earlier store the same two boxes as plain text: Admin, no quotes. The quotes are not stray; they are how a 2026 calculation writes text. For a step to move between the versions unchanged, Claris would have to make the 2025-and-earlier boxes calculations too. ai2fm converts both ways with the Target FileMaker Version setting: a name gains its quotes for 2026 and loses them for 2025, a password that itself contains a quote included. A real calculation cannot become text in 2025, so ai2fm leaves it as it is and warns on the step.

Bug 18 is still present. On 2026-10-06 Claris told us a fix for the wrong barcode types is in a pre-release build of FileMaker Pro, for an upcoming update. It is not yet tested by ai2fm.

Not yet tested by ai2fm on 26.0.3: Bugs 12–15. That includes Bugs 12 and 13, the Print PDF page setup that the 26.0.3 release notes name as fixed. Their status below is still the 26.0.2 one.

ai2fm keeps every warning and repair. Your copy of FileMaker may be 2025, 26.0.1, 26.0.2 or 26.0.3, and the step you paste may come from any of them.

Status after FileMaker Pro 26.0.2 (re-verified 2026-08-09)

FileMaker Pro 26.0.2 (26.0.2.212, 14 July 2026) states that it “fixes issues relating to copying and pasting script steps in the Script Workspace.” Claris asked us to validate that. We did — every bug on this page was re-captured and re-diffed on the new builds.

We tested on FileMaker Pro 26.0.1.51 and 26.0.2.212 installed side by side, plus FileMaker Pro 22.06 and 22.07, on macOS and Windows.

Two bugs are fixed. The other fourteen produce byte-identical clipboards on 26.0.2 — not one byte changed.

Update 2026-10-09 — Bug 9 is resolved too, by WinSoft. Starting with their 26.0.2 builds, the Middle East and Central European localized builds no longer ship the extra dictionaries. Set Dictionary offers only Claris’s standard list. Details in the bug.

For Bugs 12 and 13 we re-ran the exact reproducer files we had submitted to Claris: they still reproduce byte-for-byte on 26.0.2.

If you are still on 26.0.1, nothing changes for you. ai2fm keeps every warning and repair for both builds and picks the right behaviour from the shape of the clipboard it is given — there is no version marker in a FileMaker clipboard to switch on, so we detect the damage itself. A step copied on 26.0.1 is still warned about; the same step copied on 26.0.2 passes through clean.

Index — every bug, numbered and linkable

Each bug below has a stable anchor. Our FileMaker reproducer files link straight to the bug they were built for — for example …/claris_clipboard_bugs.html#bug-4 opens Bug 4.

Bug 1 — Perform Find by Natural Language (step 221) — the Prompt Template Name is dropped in 2025

The bug. In FileMaker 2025, copying a Perform Find by Natural Language step drops the Prompt Template Name from the clipboard. FileMaker 2026 fixed it. So a step copied in 2025 arrives with the Template Name already gone — before any tool sees it.

The files

1_Perform_Find_by_Natural_Language/1_Perform_Find_by_Natural_Language_2025.fmp12
1_Perform_Find_by_Natural_Language/1_Perform_Find_by_Natural_Language_2026.fmp12
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Corrected_AT_IDE_Result_2025.xml
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Corrected_at_IDE_Result_2025.fmscript
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Result_2025.06.fmscript
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Result_2025.07.fmscript
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Result_2026.01.fmscript
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Result_2026.02.fmscript
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Source_2025.06.xml
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Source_2025.07.xml
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Source_2026.01.xml
1_Perform_Find_by_Natural_Language/Perform_Find_by_Natural_Language_Source_2026.02.xml

What FileMaker gives us

With the Target FileMaker Version set to 2025, copy the step from 1_Perform_Find_by_Natural_Language_2025.fmp12 in FileMaker 2025 → Source_2025.xml. The <LLMCreateFind> block ends like this:

      <Parameters>
        <Calculation><![CDATA["theParameters"]]></Calculation>
      </Parameters>
      <Action>None</Action>
    </LLMCreateFind>

There is no <TemplateName> element. If a Template Name was set, it is not in the clipboard.

Now switch the Target FileMaker Version to 2026 and copy the same step from 1_Perform_Find_by_Natural_Language_2026.fmp12 in FileMaker 2026 → Source_2026.xml. The same block now contains it:

      <Parameters>
        <Calculation><![CDATA["theParameters"]]></Calculation>
      </Parameters>
      <TemplateName>
        <Calculation><![CDATA["templateName"]]></Calculation>
      </TemplateName>
      <Action>None</Action>

The difference between those two files is the bug.

What ai2fm does with the 2025 clipboard

ai2fm reads Source_2025.xml and produces Result_2025.fmscript:

# ⚠️ Warning: FileMaker 2025 dropped the Prompt Template Name when this step was copied (FM bug, fixed in 2026) — if one was set, it is already lost from this text.
# To recover it: either re-enter it here, or re-copy the step from FileMaker 2026 (with the ai2fm version set to 2026), where the copy keeps it.
Perform Find by Natural Language [ Account Name:"theAccount"; Model:"theModel"; Prompt:"thePrompt"; Get: Find Request as JSON; Parameters:"theParameters"; Response Target:myTable::myField ]

We do not invent the missing value — it isn’t there to invent. We flag it, on the step, and tell you exactly how to get it back. There are two ways.

Recovery — Path A: re-enter it in the editor

If you know the Template Name, type it back into the .fmscript line (Corrected_at_IDE_Result_2025.fmscript):

Perform Find by Natural Language [ Account Name:"theAccount"; Model:"theModel"; Prompt:"thePrompt"; Get: Find Request as JSON; Parameters:"theParameters"; Response Target:myTable::myField; Template Name:"templateName" ]

With the Target FileMaker Version set to 2025 (the version you will paste back into), convert it with ai2fm and it rebuilds the element FileMaker dropped (Corrected_AT_IDE_Result_2025.xml):

      <Parameters>
        <Calculation><![CDATA["theParameters"]]></Calculation>
      </Parameters>
      <TemplateName>
        <Calculation><![CDATA["templateName"]]></Calculation>
      </TemplateName>
      <Action>None</Action>

That clipboard pastes into FileMaker 2025 with the Template Name intact. ai2fm has healed what FileMaker’s own copy/paste could not carry.

Recovery — Path B: re-copy from FileMaker 2026

If the file is available in FileMaker 2026 (here, 1_Perform_Find_by_Natural_Language_2026.fmp12), the simpler route is to copy the step there instead — set the ai2fm Target FileMaker Version to 2026 — because 2026’s clipboard keeps the Template Name. ai2fm reads Source_2026.xml and produces Result_2026.fmscript with no warning and the name preserved:

Perform Find by Natural Language [ Account Name:"theAccount"; Model:"theModel"; Prompt:"thePrompt"; Get: Find Request as JSON; Parameters:"theParameters"; Response Target:myTable::myField; Template Name:"templateName" ]

The point

The bug is FileMaker’s; the loss is real; and ai2fm’s job is to make the loss visible and recoverable rather than silent. Both paths above are shipped as files you can run for yourself.

Reported to Claris — Data loss bug: Prompt Template Name is removed when copying/pasting Perform Find by Natural Language script steps in Script Workspace.

Bug 2 — Configure AI Account (step 212) — the XML tag was renamed, so the two versions can’t share a step

Update, 2026-09-24 — FileMaker Pro 26.0.3 fixes one direction. A step copied in FileMaker 2025 now pastes into 26.0.3 with every field. A step copied in 2026 still pastes into FileMaker 2025 blank, because 2025 does not know the corrected tag, and 2025 is not being updated. ai2fm’s target-version conversion still handles both directions.

The section below describes the bug as it was before 26.0.3.

The bug. FileMaker 2025 misspelled its own element names. FileMaker 2026 corrected the spelling — and gave neither version a fallback for the other. The result is a wall in both directions: a Configure AI Account step copied in one version, pasted into the other, comes in with Account Name, Endpoint and API key silently blanked. The paste appears to succeed; your credentials are just gone.

The files

2_Configure_AI_Account/2_Configure_AI_Account_2025.fmp12
2_Configure_AI_Account/2_Configure_AI_Account_2026.fmp12
2_Configure_AI_Account/Configure_AI_Account_Fails to paste at FM2025.06 copied from FM2026.01.fmscript
2_Configure_AI_Account/Configure_AI_Account_Fails to paste at FM2025.06 copied from FM2026.01.xml
2_Configure_AI_Account/Configure_AI_Account_Fails to paste at FM2025.06 copied from FM2026.01_new.xml
2_Configure_AI_Account/Configure_AI_Account_Fails to paste at FM2025.06 copied from FM2026.02.xml
2_Configure_AI_Account/Configure_AI_Account_Fails to paste at FM2026.01 copied from FM2025.06.fmscript
2_Configure_AI_Account/Configure_AI_Account_Fails to paste at FM2026.01 copied from FM2025.06.xml
2_Configure_AI_Account/Configure_AI_Account_Pastes correctly copied from IDE -> FM2025.06.fmscript
2_Configure_AI_Account/Configure_AI_Account_Pastes correctly copied from IDE -> FM2026.01.fmscript
2_Configure_AI_Account/Configure_AI_Account_Result_2025.06.fmscript
2_Configure_AI_Account/Configure_AI_Account_Result_2026.01.fmscript
2_Configure_AI_Account/Configure_AI_Account_Source_2025.06.xml
2_Configure_AI_Account/Configure_AI_Account_Source_2026.01.xml

The two clipboards differ in one thing: the spelling

Copy the step in FileMaker 2025 → Source_2025.xml. Note the missing n:

    <SetLLMAccout>
      <AccoutName>
        <Calculation><![CDATA["my_Local_account"]]></Calculation>
      </AccoutName>
      ...
    </SetLLMAccout>

Copy the same step in FileMaker 2026 → Source_2026.xml. FileMaker 2026 fixed the spelling:

    <SetLLMAccount>
      <AccountName>
        <Calculation><![CDATA["my_Local_account"]]></Calculation>
      </AccountName>
      ...
    </SetLLMAccount>

SetLLMAccout / AccoutName in 2025 versus SetLLMAccount / AccountName in 2026. The value inside is identical — only the tag name changed.

What FileMaker does when you paste across versions

Paste the 2025 clipboard into FileMaker 2026 (or the 2026 clipboard into 2025) and FileMaker does not reject it — it pastes a step with the fields emptied, because it doesn’t recognise the other version’s tag (Configure_AI_Account_Fails to paste at FM2026 copied from FM2025.fmscript):

Configure AI Account [ Account Name:  ; Model Provider: Custom ; Endpoint:  ; API key:  ]

The account name, endpoint and API key are gone — even though they are still sitting in the pasted clipboard’s XML. FileMaker read the wrong tag and blanked the fields. This is the dangerous kind of failure: it looks like it worked.

What ai2fm does — it reads both spellings

Point ai2fm at either clipboard and you get the same, complete, correct script. From the 2025 clipboard (Result_2025.fmscript) and from the 2026 clipboard (Result_2026.fmscript) — byte-for-byte identical:

Configure AI Account [ Account Name: "my_Local_account" ; Model Provider: Custom ; Endpoint: "https://myserver.example.com:8080/" ; API key: "sk-RZCtpWT..." ]

ai2fm knows both the 2025 and 2026 spelling and reads whichever it is handed. Nothing is blanked.

And it bridges — in both directions

The recovery is the same move both ways: read the step into ai2fm, set the Target FileMaker Version to wherever you are pasting, convert back. ai2fm writes the spelling that version expects.

• Read either clipboard → set target 2026 → the result pastes into FileMaker 2026 with every field intact (Pastes correctly copied from IDE -> FM2026.fmscript).
• Read either clipboard → set target 2025 → the result pastes into FileMaker 2025 with every field intact (Pastes correctly copied from IDE -> FM2025.fmscript).

Both round-trips produce the full step:

Configure AI Account [ Account Name: "my_Local_account" ; Model Provider: Custom ; Endpoint: "https://myserver.example.com:8080/" ; API key: "sk-RZCtpWT..." ]

The point

FileMaker 2025 and 2026 cannot exchange a Configure AI Account step — in either direction the credentials come across blank. ai2fm makes the two versions interoperable: it reads both spellings and, using the Target FileMaker Version setting, writes whichever the destination needs. This is not a repair of lost data — the data was never lost, only mis-tagged — it is a translation FileMaker itself does not perform.

Reported to Claris, case 00917117 — Backward-compatibility bug: FileMaker Pro 2026 fails to paste FileMaker Pro 2025 Configure AI Account script steps due to renamed XML tags.

Bug 3 — Configure Machine Learning Model (step 202) — the structure changed, and a bad paste becomes a different command

Update, 2026-10-09 — still present in FileMaker Pro 26.0.3. We tested it: the step is still broken in both cross-version directions, 2025 into 26.0.3 and 26.0.3 into 2025, and fields are still dropped. ai2fm repairs the step for either target version.

The bug. FileMaker 2025 and FileMaker 2026 write this step with different XML structures, and neither version’s importer accepts the other’s. Copy the step across versions and it does not error — it pastes a step that is quietly wrong in two ways: the From source field is dropped, and the Operation resets to Unload. A Vision model step becomes an Unload step. This is the most dangerous failure on this page, because the result looks like a perfectly valid command — just not the one you had.

The files

3_Configure_Machine_Learning_Model/3_Configure_Machine_Learning_Model_2025.fmp12
3_Configure_Machine_Learning_Model/3_Configure_Machine_Learning_Model_2026.fmp12
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Fails to paste at FM2025.06 copied from FM2026.01.fmscript
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Fails to paste at FM2025.06 copied from FM2026.01.xml
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Fails to paste at FM2026.01 copied from FM2025.06.fmscript
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Fails to paste at FM2026.01 copied from FM2025.06.xml
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Result_2025.06.fmscript
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Result_2026.01.fmscript
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Source_2025.06.xml
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Source_2025.07.xml
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Source_2026.01.xml
3_Configure_Machine_Learning_Model/Configure_Machine_Learning_Model_Source_2026.02.xml

The two versions store the operation differently

Copy the steps in FileMaker 2025 → Source_2025.xml. The operation is plain text inside <ConfigureCoreML>, and the field is emitted twice:

    <Field table="myTable" id="7" name="myField"/>
    <ConfigureCoreML>Vision<Name><Calculation><![CDATA["visionModel"]]></Calculation></Name></ConfigureCoreML>
    <Field table="myTable" id="7" name="myField"/>

Copy the same steps in FileMaker 2026 → Source_2026.xml. The operation moved into an <Operation> child element, and the field is emitted once:

      <ConfigureCoreML>
        <Operation>Vision</Operation>
        <Name>
          <Calculation><![CDATA["visionModel"]]></Calculation>
        </Name>
      </ConfigureCoreML>
      <Field table="myTable" id="7" name="myField"/>

Same step, same values — a completely different XML shape.

What FileMaker does when you paste across versions

Paste the 2025 clipboard into FileMaker 2026 (or the 2026 clipboard into 2025) and FileMaker cannot read the other version’s structure. It does not reject the paste — it produces a step with both the operation and the source wrong (Configure_Machine_Learning_Model_Fails to paste at FM2026 copied from FM2025.fmscript):

Configure Machine Learning Model [ Operation: Unload ; Name: "visionModel" ]
Configure Machine Learning Model [ Operation: Unload ; Name: "visionModel" ]

Compare to what you had — Operation: Vision / Operation: General, each From: myTable::myField. After the cross-version paste, every operation has collapsed to Unload and the From source is gone. The failure is deterministic and it happens in both directions. A model step silently becomes an unload.

What ai2fm does — it reads both structures

Point ai2fm at either clipboard and you get the same, complete, correct script. From the 2025 clipboard (Result_2025.fmscript) and from the 2026 clipboard (Result_2026.fmscript) — byte-for-byte identical:

Configure Machine Learning Model [ Operation: Vision ; Name: "visionModel" ; From: myTable::myField ]
Configure Machine Learning Model [ Operation: General ; Name: "visionModel" ; From: myTable::myField ]

The real operations survive, and the From field survives. ai2fm understands both the 2025 text-in-<ConfigureCoreML> shape and the 2026 <Operation>-child shape.

And it bridges — in both directions

Read the step into ai2fm, set the Target FileMaker Version to wherever you are pasting, convert back — ai2fm writes the structure that version expects, operation and source intact. Read either clipboard → set target 2026 → pastes correctly into FileMaker 2026. Read either → set target 2025 → pastes correctly into FileMaker 2025.

The point

FileMaker 2025 and 2026 cannot exchange a Configure Machine Learning Model step: across versions the operation resets to Unload and the source field vanishes — a valid-looking step that does the wrong thing. ai2fm reads both structures, keeps the operation and the source, and writes whichever shape the destination needs. Nothing is lost — the values were always in the XML; FileMaker just could not read the other version’s layout.

Reported to Claris, case 00917153 — Backward-compatibility bug: FileMaker Pro 2026 fails to paste FileMaker Pro 2025 Configure Machine Learning Model script steps.

Bug 4 — Set Data File Position (step 195) — the New position value is dropped on copy in 2026

The bug. FileMaker 2026 drops the New position value (the byte offset to seek to) from the clipboard when you copy a Set Data File Position step. The value is fine in your file and fine in the Script Workspace — it is lost only in the clipboard, at the moment of copy. FileMaker 2025 copies the same step correctly. Because the loss is in the clipboard, it travels with it: paste the 2026-copied step back into FileMaker — 2026 or 2025 — and the New position is gone in both.

The files

4_Set_Data_File_Position/4_Set_Data_File_Position_2025.fmp12
4_Set_Data_File_Position/4_Set_Data_File_Position_2026.fmp12
4_Set_Data_File_Position/Set_Data_File_Position_Result_2025.06.fmscript
4_Set_Data_File_Position/Set_Data_File_Position_Result_2025.06.xml
4_Set_Data_File_Position/Set_Data_File_Position_Result_2026.01.fmscript
4_Set_Data_File_Position/Set_Data_File_Position_Source_2025.06.xml
4_Set_Data_File_Position/Set_Data_File_Position_Source_2026.01.xml
4_Set_Data_File_Position/Set_Data_File_Position_Source_2026.02.xml

What FileMaker gives us

Copy the three steps in FileMaker 2025 → Source_2025.xml. Every step carries its <position>:

  <Step enable="True" id="195" name="Set Data File Position">
    <Calculation><![CDATA[myTable::myField]]></Calculation>
    <position>
      <Calculation><![CDATA[$thePosition]]></Calculation>
    </position>
  </Step>

Copy the same three steps in FileMaker 2026 → Source_2026.xml. The <position> element is gone from every one — only the File ID survives:

  <Step enable="True" id="195" name="Set Data File Position">
    <DisableStepCollapsed state="False"/>
    <Calculation><![CDATA[myTable::myField]]></Calculation>
  </Step>

Same step, same value in the file — but the 2026 clipboard no longer contains the New position. That absence is the bug, and it is why pasting the 2026 clipboard into either version produces a step with New position blank.

What ai2fm does with the 2025 clipboard

ai2fm reads Source_2025.xml and produces Result_2025.fmscript, every value intact:

Set Data File Position [ File ID: myTable::myField ; New position: $thePosition ]
Set Data File Position [ File ID: myTable::myField ; New position: "thePosition" ]
Set Data File Position [ File ID: myTable::myField ; New position: myTable::myNumber ]

What ai2fm does with the 2026 clipboard — it flags the loss

The 2026 clipboard has no New position to read, so ai2fm cannot invent one. What it does instead is refuse to let the loss pass silently: it marks every affected step with a warning (Result_2026.fmscript):

# ⚠️ Warning: check the New position value — FileMaker 2026 may have dropped it on copy; re-enter it here if it was set.
Set Data File Position [ File ID: myTable::myField ; New position:  ]
# ⚠️ Warning: check the New position value — FileMaker 2026 may have dropped it on copy; re-enter it here if it was set.
Set Data File Position [ File ID: myTable::myField ; New position:  ]
# ⚠️ Warning: check the New position value — FileMaker 2026 may have dropped it on copy; re-enter it here if it was set.
Set Data File Position [ File ID: myTable::myField ; New position:  ]

Without ai2fm the empty New position is indistinguishable from a step that never had one — FileMaker gives no sign anything was lost. The warning turns a silent drop into a visible one.

Recovery — re-enter it, and ai2fm rebuilds it

Type the New position back onto each flagged line — a variable, a literal, or a field, whichever it was. This is the whole repair, and it is done in the text you are already reading:

Set Data File Position [ File ID: myTable::myField ; New position: $thePosition ]
Set Data File Position [ File ID: myTable::myField ; New position: "thePosition" ]
Set Data File Position [ File ID: myTable::myField ; New position: myTable::myNumber ]

Convert that with ai2fm and it rebuilds the <position> element FileMaker dropped (Result_2025.xml) — the part you never have to look at, shown here only as proof the value really is back in the clipboard:

  <Step enable="True" id="195" name="Set Data File Position">
    <Calculation><![CDATA[myTable::myField]]></Calculation>
    <position>
      <Calculation><![CDATA[$thePosition]]></Calculation>
    </position>
  </Step>

That clipboard pastes into FileMaker with the New position intact.

The point

FileMaker 2026 loses the New position the moment you copy the step, in a way nothing on screen reveals. ai2fm cannot recover a value that never reached the clipboard — but it makes the loss visible, flags exactly which steps are affected, and rebuilds the value the instant you supply it. A silent drop becomes a caught one.

Reported to Claris, case 00921415 — Bug report: FileMaker Pro 2026 drops the New position value from Set Data File Position on copy to the clipboard.

Bug 5 — Perform RAG Action — Add Data (step 219) — the Response Target is dropped, but only for the (Async) sources

The bug. In FileMaker 2026, a Perform RAG Action step with Action: Add Data can store a Response Target — the field or variable that receives the document ID the RAG server returns. Copying that step keeps the Response Target when the source is From Container or From File, but drops it when the source is the (Async) variant (From Container (Async) / From File (Async)). Same step, same option — the loss depends entirely on which data source you picked. This is a 2026-only step, so there is no earlier version to compare against; the bug is FileMaker 2026 losing part of its own new feature on copy.

The files

5_Perform_RAG_Action/5_Perform_RAG_Action_2025.fmp12
5_Perform_RAG_Action/5_Perform_RAG_Action_2026.fmp12
5_Perform_RAG_Action/Perform_RAG_Action_Result_2026.01.fmscript
5_Perform_RAG_Action/Perform_RAG_Action_Result_2026.02.fmscript
5_Perform_RAG_Action/Perform_RAG_Action_Result_Corrected_at_IDE_2026.fmscript
5_Perform_RAG_Action/Perform_RAG_Action_Source_2026.01.xml
5_Perform_RAG_Action/Perform_RAG_Action_Source_2026.02.xml
5_Perform_RAG_Action/Perform_RAG_Action_Source_Corrected_at_IDE_2026.xml

What FileMaker gives us

Copy the steps → Source_2026.xml. The Response Target is stored as <Field type="AddDataResponse"> inside <RAGSpace>. For the two From Container steps it is present:

      <DataSource>FromContainer</DataSource>
      <Field type="AddDataResponse">$theResponse</Field>

      <DataSource>FromContainer</DataSource>
      <Field type="AddDataResponse" table="myTable" id="19" name="TypeID"/>

For the two From Container (Async) steps, the <DataSource> is there but the AddDataResponse field is simply gone — FileMaker dropped it:

      <DataSource>FromContainerAsync</DataSource>
      <RAGSpaceTokensPerTextChunk>
        <Calculation><![CDATA[$tokens]]></Calculation>
      </RAGSpaceTokensPerTextChunk>

The difference between the two blocks — same option, present for one source, absent for the other — is the bug.

What ai2fm does — keep what’s there, flag what’s gone

ai2fm reads Source_2026.xml and produces Result_2026.fmscript. The From Container steps come through complete — Response Target and all:

Perform RAG Action [ RAG Account Name: "theAccount" ; Space ID: "theID" ; Action: Add Data ; RAG Data: From Container ; Container Field: myTable::myContainer ; Detect vertical text ; Tokens per Text Chunk: $tokens ; Response Target: $theResponse ]
Perform RAG Action [ RAG Account Name: "theAccount" ; Space ID: "theID" ; Action: Add Data ; RAG Data: From Container ; Container Field: myTable::myContainer ; Detect vertical text ; Tokens per Text Chunk: $tokens ; Response Target: myTable::TypeID ]

The From Container (Async) steps have no Response Target to read, so ai2fm flags each one instead of letting the loss pass unseen:

# ⚠️ Warning: for Action: Add Data with an (Async) source, FileMaker 2026 drops the Response Target (the returned document ID) from the clipboard on copy — an FM2026 platform defect (reported to Claris). Re-enter it here if one was set and ai2fm will rebuild it on the way back into FileMaker.
Perform RAG Action [ RAG Account Name: "theAccount" ; Space ID: "theID" ; Action: Add Data ; RAG Data: From Container (Async) ; Container Field: myTable::myContainer ; Detect vertical text ; Tokens per Text Chunk: $tokens ]

This is the important half of the fix: ai2fm does not blindly drop the Response Target for every Add-Data step. It keeps the value FileMaker kept, and warns only on the (Async) steps where FileMaker actually lost it.

Recovery — re-enter it, and ai2fm rebuilds it

Type the Response Target back onto the flagged (Async) line and convert with ai2fm. It rebuilds the <Field type="AddDataResponse"> element FileMaker dropped, in the right place inside <RAGSpace> (Source_Corrected_at_IDE_2026.xml):

      <DataSource>FromContainerAsync</DataSource>
      <Field type="AddDataResponse">$theResponse</Field>

Read that healed clipboard back and every step — sync and async — carries its Response Target, with no warning left:

Perform RAG Action [ RAG Account Name: "theAccount" ; Space ID: "theID" ; Action: Add Data ; RAG Data: From Container (Async) ; Container Field: myTable::myContainer ; Detect vertical text ; Tokens per Text Chunk: $tokens ; Response Target: $theResponse ]

The point

FileMaker 2026 keeps the Add-Data Response Target for the synchronous sources and silently drops it for the (Async) ones. ai2fm mirrors the truth exactly: it preserves the value where FileMaker preserves it, flags the precise steps where FileMaker lost it, and rebuilds it the moment you re-enter it. Nothing correct is thrown away, and nothing lost is left silent.

Update 2026-10-18 — FileMaker 26.0.3: partly fixed

On FileMaker Pro 26.0.3, ai2fm tested an Add Data step (From Text) whose Response Target carries a calculated repetition, as a field and as a variable.

Copying works. The clipboard holds the Response Target and its repetition, inside <RAGSpace>:

      <DataSource>FromText</DataSource>
      <InputText>
        <Calculation><![CDATA["the text"]]></Calculation>
      </InputText>
      <Field type="AddDataResponse" table="myTable" id="7" repetition="0" name="myField"/>
      <Repetition>
        <Calculation><![CDATA[5+$other]]></Calculation>
      </Repetition>

Pasting does not. Paste that same XML, FileMaker’s own, back into the Script Workspace, and the repetition comes back empty:

Perform RAG Action [RAG Account Name:"theAccount"; Space ID:"theID"; Action:Add Data; RAG Data:From Text; "the text"; Response Target:myTable::myField[]]
Perform RAG Action [RAG Account Name:"theAccount"; Space ID:"theID"; Action:Add Data; RAG Data:From Text; "the text"; Response Target:$theVar[]]

FileMaker writes a format it then cannot read back. The fix of 26.0.2 restored the Response Target itself, but not a calculated repetition on it.

What ai2fm does. ai2fm writes the Response Target and its repetition exactly as FileMaker’s own copy does, and puts a warning above the step, naming the calculation to re-enter by hand in the Script Workspace.

Not yet tested by ai2fm on 26.0.3: a literal repetition (myField[2]), and the (Async) sources.

Reported to Claris, case 00916818 — Data loss bug: “Response Target” is removed when copying/pasting Perform RAG Action (Add Data) script steps in Script Workspace.

Bug 6 — Read from Data File (step 193) — the Amount is dropped on copy, and in 2025 two very different scripts look identical

The bug. In FileMaker 2026, copying a Read from Data File step drops the Amount (bytes) value — the number of bytes to read — from the clipboard. The step in your file still holds it. Only the copy loses it. What makes this one worth reading twice is what happens next in FileMaker 2025: depending on how the step got there, the Amount is either hidden but alive or gone for good — and the two are indistinguishable on screen.

The files

6_Read_from_Data_File/6_Read_from_Data_File_2025.fmp12
6_Read_from_Data_File/6_Read_from_Data_File_2026.fmp12
6_Read_from_Data_File/Read_from_Data_Created_in_2026.01_Opened_in_2025.06.xml
6_Read_from_Data_File/Read_from_Data_Created_in_2026.01__Opened_in_2025.06_and_Corrected.xml
6_Read_from_Data_File/Read_from_Data_File_Corrected_at_IDE_2026.01.fmscript
6_Read_from_Data_File/Read_from_Data_File_Corrected_at_IDE_2026.01.xml
6_Read_from_Data_File/Read_from_Data_File_Result_2026.01.fmscript
6_Read_from_Data_File/Read_from_Data_File_Source_2026.01.xml
6_Read_from_Data_File/Read_from_Data_File_Source_2026.02.xml

What FileMaker gives us

Copy the steps in FileMaker 2026 → Source_2026.xml. Every step arrives without its Amount — there is no <Count> element anywhere in the file:

  <Step enable="True" id="193" name="Read from Data File">
    <DisableStepCollapsed state="False"/>
    <DataSourceType value="3"/>
    <Calculation><![CDATA[myTable::TypeID]]></Calculation>
  </Step>

A correct clipboard carries the value like this — the shape FileMaker 2025 writes, and the shape ai2fm rebuilds:

    <Count>
      <Calculation><![CDATA[10]]></Calculation>
    </Count>

What ai2fm does — it flags every affected step

ai2fm reads Source_2026.xml and produces Result_2026.fmscript. All six steps come through with the Amount blank, and each one is marked:

# ⚠️ Warning: the Amount (bytes) value is not in this copy — FileMaker left it out when the step was copied, even though the step still holds it.
# Re-enter the Amount here and paste the step back into FileMaker: that repairs the step for good — copy it again afterwards and the value stays.
Read from Data File [ File ID: myTable::TypeID ; Amount (bytes):  ; Target:  ; Read as: Bytes ]

Recovery — re-enter it, and ai2fm repairs the step permanently

Type the Amounts back onto the flagged lines (Corrected_at_IDE_2026.fmscript):

Read from Data File [ File ID: myTable::TypeID ; Amount (bytes): 10 ; Target:  ; Read as: Bytes ]
Read from Data File [ File ID: myTable::TypeID ; Amount (bytes): $theAmount ; Target: myTable::myField ; Read as: Bytes ]

Convert that with ai2fm and it rebuilds the <Count> element FileMaker left out, on all six steps (Corrected_at_IDE_2026.xml):

    <Count>
      <Calculation><![CDATA[$theAmount]]></Calculation>
    </Count>

Paste that back into FileMaker and the step is repaired for good — copy it again afterwards and the Amount comes with it. This is the one bug on this page where ai2fm does not merely surface the loss: it puts the value back into your solution permanently.

The part that should worry you: in 2025, two different scripts look the same

Take that same 2026 file to FileMaker 2025, by the two routes a developer would actually use, and the Script Workspace renders both the same way — no Amount shown at all:

Read from Data File [File ID:myTable::TypeID; Target:; Read as:Bytes]

They are not the same. Open the step’s gear, click Amount → Specify…, and:

• The file simply opened in 2025 — the Specify dialog shows 10. The value is intact and will execute. It is only the step rendering that hides it.
• The step copy-pasted from 2026 — the Specify dialog is empty. The value is gone.

One script silently enforces a read limit; the other silently has none; and nothing on screen tells them apart. That, more than the dropped element, is the real hazard here.

Three ways to get the Amount back

• Author in 2025 to begin with. FileMaker 2025 writes the Amount into the clipboard correctly, so the problem never starts.
• If the file was opened in 2025: open the Amount gear on the step and save. The value is already there — saving makes FileMaker write it out properly again. No tooling needed. (This works only on this route, because the value survived; there is nothing to reveal on a pasted step.)
• In any version, via ai2fm: re-enter the Amount in the editor and paste the step back. ai2fm rebuilds the element and the repair sticks in 2025 and 2026 alike.

One honest caveat: a step copied out of a 2025 file gives no sign of trouble, because in 2025 an empty Amount is a perfectly normal thing to have — ai2fm cannot tell “never set” from “lost on the way here”. If a 2025 file began life in 2026, check the Amount gear on these steps before trusting a blank.

Reported to Claris, case 00921417 — Bug Report: FileMaker Pro 2026 drops the “Amount (bytes)” value from Read from Data File on copy to the clipboard.

Bug 7 — Configure Prompt Template (step 226) — a Google step pastes back as OpenAI

The bug. In FileMaker 2026, a Configure Prompt Template step set to Model Provider: Google does not survive a copy and paste. The pasted step comes back as OpenAI. Every other provider — ChatGPT, Anthropic, Cohere, Custom — is preserved correctly. Only Google is affected, and the step then runs against a different AI provider than the one the developer chose.

The files

7_Configure_Prompt_Template/7_Configure_Prompt_Template_2026.fmp12
7_Configure_Prompt_Template/Configure_Prompt_Template_Result_2026.01.fmscript
7_Configure_Prompt_Template/Configure_Prompt_Template_Result_2026.02.fmscript
7_Configure_Prompt_Template/Configure_Prompt_Template_Result_2026_2.fmscript
7_Configure_Prompt_Template/Configure_Prompt_Template_Source_2026.01.xml
7_Configure_Prompt_Template/Configure_Prompt_Template_Source_2026.02.xml
7_Configure_Prompt_Template/Configure_Prompt_Template_Source_2026_2.xml

What FileMaker gives us

Copy the steps → Source_2026.xml. Four of the five providers serialize their value as you would expect:

      <ModelProvider>Anthropic</ModelProvider>

Google does not. It serializes as an empty element — the tag is there, the value is not:

      <ModelProvider/>

That is the whole bug, and everything follows from it. When FileMaker pastes this step back, it finds an empty provider, falls back to its default — OpenAI — and writes that in. The developer’s choice is gone, replaced by a valid-looking setting that happens to be the wrong one. Nothing on screen reports a problem.

What ai2fm does — it reads the empty element as Google

ai2fm knows that in this step an empty <ModelProvider/> means Google, because no other provider serializes empty. Reading the same clipboard, it produces Result_2026.fmscript with the provider intact:

Configure Prompt Template [ Template Name: "Name" ; Model Provider: Anthropic ; Template Type: SQL Query ; … ]
Configure Prompt Template [ Template Name: "Name" ; Model Provider: Google ; Template Type: SQL Query ; … ]

Convert that back and paste it into FileMaker, and the step arrives as Google — the setting the developer actually made. The choice survives the ai2fm round trip where it does not survive FileMaker’s own copy and paste.

This holds for disabled steps too. We checked all five providers in both enabled and disabled form — ten steps — and the serialization is identical in both states: only Google comes across empty, and ai2fm recovers it in both cases.

// Configure Prompt Template [ Template Name: "Name" ; Model Provider: Google ; Template Type: SQL Query ; … ]

The point

FileMaker writes Google as an absence and then reads that absence as OpenAI. The information needed to get it right is present in the clipboard — an empty provider element is unambiguous, because no other provider produces one — so this is a case where the correct value was recoverable all along. ai2fm recovers it. FileMaker, reading its own file, does not.

Reported to Claris — Data loss bug: “Model Provider: Google” is lost on copy/paste of Configure Prompt Template script steps in Script Workspace (pastes back as OpenAI).

Bug 8 — Refresh Portal (step 180) — a parameter that exists, displays, and cannot be set

The bug. Refresh Portal carries a Repetition parameter that no developer can reach. FileMaker’s Script Workspace displays it — Refresh Portal [Object Name: "thePortal"; Repetition: 1] — and the copied clipboard serializes it. But the step’s options panel offers no field for it, so it cannot be entered, edited, or removed. It appears on its own when an Object Name is set, its value is always 1, and it is absent from both the documentation and the step’s own SaXML.

The files

8_Refresh_Portal/8_Refresh_Portal_2026.fmp12
8_Refresh_Portal/Refresh_Portal_Options_dialog_has_NO_Repetition_field_MAC_2026.02.png
8_Refresh_Portal/Refresh_Portal_Result_2026.01.fmscript
8_Refresh_Portal/Refresh_Portal_Script_Workspace_SHOWS_phantom_Repetition_1_MAC_2026.02.png
8_Refresh_Portal/Refresh_Portal_Source_2026.01.xml
8_Refresh_Portal/Refresh_Portal_Source_2026.02.xml

What FileMaker gives us

Copy the steps → Source_2026.xml. Each Refresh Portal step with an Object Name carries the element:

  <Step enable="True" id="180" name="Refresh Portal">
    <DisableStepCollapsed state="False"/>
    <ObjectName>
      <Calculation><![CDATA["thePortal"]]></Calculation>
    </ObjectName>
    <Repetition>
      <Calculation><![CDATA[1]]></Calculation>
    </Repetition>
  </Step>

In our capture, six of the seven steps carry <Repetition>, and the value is 1 every time. The one step without it is the one with no Object Name — the tell that it materializes as a side effect of filling in the Object Name, rather than as something anybody chose.

Why we treat it as noise rather than a parameter

• It cannot be set. The step’s options panel has no repetition field. There is no way for a developer to enter, change, or clear it.
• It never varies. Every occurrence is 1. No other value has ever been produced.
• It is not documented. The Claris help page for Refresh Portal lists exactly one option: Object Name.
• It is not in the step’s own SaXML. FileMaker’s canonical serialization of the same step reports membercount="1" with a single <Parameter type="Object">. There is no Repetition member.

So the value is real enough to display and to serialize, and at the same time inert: nobody put it there, nobody can change it, and FileMaker’s own canonical format does not record it.

What ai2fm does — it leaves the phantom out

We could reproduce what the clipboard says. We deliberately do not, because writing Repetition: 1 into your script would present a control that does not exist — a parameter a developer might reasonably try to edit, in a step that offers no way to do so. Reading the clipboard above, ai2fm emits the step as a developer can actually work with it:

Refresh Portal [ Object Name: "thePortal" ]
Refresh Portal [ Object Name: $thePortal ]
Refresh Portal [ Object Name: myTable::myField ]

No Repetition — in enabled and disabled steps alike. This is a deliberate editorial choice, not an oversight: we follow the documented step and its own SaXML, which agree with each other.

The point

Most entries on this page are about information going missing. This one is about information that should never have been surfaced. A parameter you cannot set is not a setting — and two clipboards that differ only by its presence describe exactly the same step, so carrying it through would produce spurious differences when you diff or version your scripts.

Reported to Claris, case 00920831 — Bug Report: Refresh Portal emits a phantom “Repetition” parameter.

Seen on screen (FileMaker Pro 26.0.2.212, macOS)

The dialog and the script line disagree in the same session. The Options dialog offers only Object Name — there is no repetition field anywhere in it — while the Script Workspace prints Repetition: 1 on every step.

That is the whole bug in two screenshots: FileMaker displays a parameter it gives you no way to set.

Bug 9 — Set Dictionary (step 209) — on WinSoft localized builds the spelling language becomes dialog text

Update, 2026-10-09 — resolved by WinSoft, by removing the dictionaries. WinSoft told us the issue is fixed starting with FileMaker Pro 26.0.2. We tested their 26.0.2 builds. The Middle East and Central European builds no longer ship the extra localized dictionaries: Set Dictionary now offers only Claris’s standard list, the same as the USA build. Every language a step can store now has a name in the string table.

Existing scripts: a script made on an earlier ME build with one of the removed dictionaries chosen (Greek, Russian, Hebrew, Slovenian and the rest) opens on the 26.0.2 build with the language empty, Set Dictionary [Spelling Language:]. That is how such scripts always opened on the CE and USA builds. Choose one of the standard languages again.

The section below describes the bug as it was before 26.0.2.

The bug. This one is not Claris’s. On the WinSoft Middle East localized build of FileMaker, a Set Dictionary step loses its spelling language the moment you copy, print, or export it. Copy and paste the step and every localized dictionary comes back as UK English. Print it or Save as XML and the language is replaced by unrelated interface text — Expire password, Account Name:, Pages:. The step in the file is fine; all three serializations read the same corrupted table.

The files

9_Set_Dictionary/9_DictionaryBug.fmp12
9_Set_Dictionary/winsoft.fmscript
9_Set_Dictionary/winsoft.xml
9_Set_Dictionary/winsoft_Print.fmscript
9_Set_Dictionary/winsoft_SaXML.xml

Why it happens

Set Dictionary stores the chosen language as a small enum id, then resolves that id to a display name through the build’s localization string table. Claris ships thirteen languages at values 1 to 13, and every build has names for them:

Português (Brasil) = 1        US English (Medical) = 8
Português (Portugal) = 2      Deutsch (Neue Regeln) = 9
Nederlands = 3                Schweizerdeutsch = 10
Deutsch (Alte Regeln) = 4     US English = 11
Español = 5                   Svenska = 12
Italiano = 6                  UK English = 13
Français = 7

The WinSoft ME installer adds its own dictionaries on top — a WinsoftDictionaries folder inside the FileMaker application directory holding Greek, Russian, Hebrew, Slovenian and others. Selecting one stores an enum id outside 1–13, and WinSoft never added matching names to the string table. The lookup falls through and returns whatever string happens to sit at that offset:

US English = 11                       ← the only value inside 1-13; resolves correctly
Expire password = 101                 Source field 0 import to = 113
Account Name: = 102                   Data contains column names = 117
Password: = 103                       All Pages = 118
Old Password: = 105                   Pages: = 119
New Account = 110                     Number pages from: = 121

Every one of those is a string from the Change Password dialog, the Import field-mapping screen, or the Print page-range controls. None is a spelling language.

One file, three states — and one line that proves it

The test file holds the same forty-two localized dictionary steps plus, on the last line, a step set to US English. Watch that last line:

• Opened on the ME build, the script renders correctly: Български, Ελληνικά, עברית, Русский, Türkçe, ไทย and the rest, each showing its real language. Line 43 shows US English.
• Copy the script and paste it, and all forty-two collapse to UK English. Line 43 still shows US English.
• Open the same file on a CE or USA build, and all forty-two render empty — Set Dictionary [Spelling Language:] with nothing at all. Line 43 still shows US English.

US English is enum 11, inside the standard range, so it has a real name in every build’s table. It is the one value that survives all three states — which is the root cause demonstrated rather than argued. The languages that break are exactly the ones whose enum id has no name entry.

What this means for any tool

There is no clean format to recover from. The clipboard, the printed output and the Save-as-XML export all read the same table, so all three carry the same corruption. A tool cannot repair this from the outside, and neither can we: the correct language name simply does not exist anywhere in the build’s resources. We build our Set Dictionary support from the official Claris build, where the table is correct, so the step ships clean.

What we asked WinSoft for was the missing value-to-name entries for the dictionaries they ship beyond the standard thirteen; the 1–13 table was already correct. WinSoft chose the other remedy in 26.0.2: they removed those dictionaries (see the update at the top of this bug).

Reported to WinSoft — ticket [rt2.winsoft.fr #1683], where WinSoft reproduced and confirmed all three failure modes on the ME build, with their own screenshots. Claris is investigating too (Claris case 00920939): although this is a localized-build defect rather than their own, Claris forwarded the report to their Testing and Development teams (2026-08-06) to check whether anything in the version of FileMaker Pro they support needs correcting. Also posted to the Claris community so other users of the localized builds can find it: Bug Report: WinSoft (ME/CE localized) FileMaker builds corrupt Set Dictionary’s language on copy/print/SaXML.

Bug 10 — Execute SQL (step 117) — the Save credentials flag is flipped, and 2025 and 2026 store the credentials differently

Update, 2026-10-09 — we had the second half wrong. This section used to say that FileMaker 2026 wraps the user name in “stray quotes” and that you should remove them. The quotes are not stray. In FileMaker 2026 the user name and password are calculations, and the quotes are how a calculation writes text. Removing them in 2026 breaks the step. The section below is corrected, and so is ai2fm: the “remove the quotes” warning is gone.

The bug. An Execute SQL step that connects to an ODBC data source has two settings that do not survive a move between FileMaker 2025 and 2026: the Save credentials checkbox, and the user name and password. The first is a FileMaker 2026 defect. The second is a change of design: FileMaker 2026 made the two credential boxes calculations, while FileMaker 2025 and earlier keep them as plain text. ai2fm warns on the first and converts the second.

The files

10_Execute_SQL/10_Execute_SQL_2025.fmp12
10_Execute_SQL/10_Execute_SQL_2026.fmp12
10_Execute_SQL/Execute_SQL_2026_AFTER_save_flags1624_CORRUPTED.xml
10_Execute_SQL/Execute_SQL_2026_BEFORE_save_flags536_CORRECT.xml
10_Execute_SQL/Execute_SQL_Copied_from_2026.01_Corrected_Crendetials_after_Paste.fmscript
10_Execute_SQL/Execute_SQL_Copied_from_2026.01_Corrected_Crendetials_after_Paste.xml
10_Execute_SQL/Execute_SQL_Copied_from_2026.01_wrong Crendetials_on_Paste.fmscript
10_Execute_SQL/Execute_SQL_Copied_from_2026.01_wrong Crendetials_on_Paste.xml
10_Execute_SQL/Execute_SQL_Result_2025.06.fmscript
10_Execute_SQL/Execute_SQL_Result_2026.01.fmscript
10_Execute_SQL/Execute_SQL_Source_2025.06.xml
10_Execute_SQL/Execute_SQL_Source_2025.07.xml
10_Execute_SQL/Execute_SQL_Source_2026.01.xml
10_Execute_SQL/Execute_SQL_Source_2026.02.xml
10_Execute_SQL/Execute_SQL_pasted_from_2025.06_Result.fmscript
10_Execute_SQL/Execute_SQL_pasted_from_2025.06_Result.xml

One — you say “don’t save my credentials”, FileMaker 2026 saves them anyway

Set the ODBC Connect dialog’s “Save user name and password” checkbox to off, with no user name or password, and save the step. Copy it, and the clipboard says the opposite:

<Profile QueryType="Query" flags="1624" password="" UserName="" dsn="gemini" DataType="ODBC"/>

The flags integer encodes that checkbox, and 1624 means on — even though you set it off, and even though there is nothing to save (user name and password are both empty). FileMaker 2026 re-checks the box for you and keeps it checked. The error is the flag itself: your deliberate choice not to store credentials has been silently reversed to “store them”. Because the wrong value is baked into the copied step, it stays wrong wherever the step goes — pasted into 2026 or 2025 alike.

ai2fm reads that clipboard and flags it, on the step:

# ⚠️ You set "Save credentials" to Off, but FileMaker 2026 turned it back On and saved no credentials — this step will prompt for a user name and password when it runs.
Execute SQL [ With dialog: Off ; ODBC Data Source: gemini ; Save credentials: On ]

Two — in 2026 the credentials are calculations, in 2025 they are text

Since FileMaker 2026, “ODBC data source credentials can now be specified by a calculation” (Claris release notes, 26.0.1). The two boxes hold calculations now, so a literal name is written the way any calculation writes text: in quotes.

Copy a step with the user name root in FileMaker 2025 (Execute_SQL_Source_2025.06.xml):

<Profile QueryType="Query" flags="600" password="12345678" UserName="root" dsn="gemini" DataType="ODBC"/>

The same step in FileMaker 2026 (Execute_SQL_Source_2026.01.xml):

<Profile QueryType="Calculation" flags="1624" password="12345678" UserName="&quot;root&quot;" dsn="gemini" DataType="ODBC"/>

The user name is the string literal "root". The password needs no quotes because 12345678 is a number, and a number evaluates to its own digits. FileMaker 2026 evaluates both when the step runs: an unquoted Get ( AccountName ) signs in as the current account.

That is correct in 2026. The trouble starts when the step moves:

• 2026 → 2025. FileMaker 2025 reads the box as text, so it signs in as "root", quotes included. The connection fails and nothing on screen says why (Execute_SQL_Copied_from_2026.01_wrong Crendetials_on_Paste). A real calculation, such as Get ( AccountName ), cannot work in 2025 at all: 2025 sends the characters as typed.
• 2025 → 2026. Pasted directly, FileMaker 2026 adds the quotes itself (Execute_SQL_pasted_from_2025.06_Result).

No FileMaker update can fix this. For a step to move unchanged, FileMaker 2025 and earlier would have to treat the two boxes as calculations too.

What ai2fm does — it writes the credentials for the version you paste into

ai2fm shows the credentials exactly as FileMaker stored them:

Execute SQL [ With dialog: Off ; ODBC Data Source: gemini ; User Name: "root" ; Password: 12345678 ; Save credentials: On ]

When you convert back, the Target FileMaker Version setting decides what FileMaker receives:

We tested the two quote passwords against a real MariaDB server: both connect, in FileMaker 2026 and in FileMaker 2025.

A calculation cannot become text, so for target 2025 ai2fm leaves it as it is and says so on the step. The warning names the box, never its value:

# ⚠️ FileMaker 2025 cannot evaluate the ODBC User Name: it stores the text as typed, so the connection will fail. Replace it with the literal value.
Execute SQL [ With dialog: Off ; ODBC Data Source: gemini ; User Name: Get ( AccountName ) ; Password: "admin" ; Save credentials: On ]

The point

These are two different problems. The Save credentials flag is a FileMaker 2026 defect, written into the step before any tool sees it, and ai2fm warns about it on the exact step. The credentials are a change of design that no update will reverse. ai2fm writes each value the way the FileMaker you paste into reads it, and warns where no conversion is possible.

Reported to Claris, case 00919882 — Bug Report: FileMaker Pro Execute SQL / Import Records ODBC “Save user name and password” flag is not preserved across versions.

(The same Claris report also covers Import Records with an ODBC source — the same two issues, documented next.)

Bug 11 — Import Records ODBC (step 35) — the same two issues, on your data imports

Update, 2026-10-09: the quotes around the user name are not stray. In FileMaker 2026 the credentials are calculations. See Bug 10; this section is corrected the same way.

The bug. Import Records can pull its rows from an ODBC data source, using the exact same connection settings as Execute SQL, and it has the exact same two issues. The Save credentials flag is set on with nothing to save, a FileMaker 2026 defect. And the user name and password are calculations in FileMaker 2026 but plain text in 2025 and earlier. If you move scripts across versions, every ODBC import is affected the same way an Execute SQL step is.

The files

Windows:

11_Import_Records_ODBC/MAC/11_Import_Records_from_Odbc_MAC_2026.fmp12
11_Import_Records_ODBC/MAC/Import_Records_ODBC_Result_2026.01.fmscript
11_Import_Records_ODBC/MAC/Import_Records_ODBC_Source_2026.01.xml
11_Import_Records_ODBC/MAC/Import_Records_ODBC_Source_2026.02.xml
11_Import_Records_ODBC/WIN/11_Import_Records_from_Odbc_2025.fmp12
11_Import_Records_ODBC/WIN/11_Import_Records_from_Odbc_2026.fmp12
11_Import_Records_ODBC/WIN/Import_Records_ODBC_Result_2025.06.fmscript
11_Import_Records_ODBC/WIN/Import_Records_ODBC_Result_2026.01.fmscript
11_Import_Records_ODBC/WIN/Import_Records_ODBC_Source_2025.06.xml
11_Import_Records_ODBC/WIN/Import_Records_ODBC_Source_2025.07.xml
11_Import_Records_ODBC/WIN/Import_Records_ODBC_Source_2026.01.xml
11_Import_Records_ODBC/WIN/Import_Records_ODBC_Source_2026.02.xml
11_Import_Records_ODBC/WIN/Import_Records_from_ODBC_Copied_from_2026.01_wrong Crendetials_on_Paste.fmscript
11_Import_Records_ODBC/WIN/Import_Records_from_ODBC_Copied_from_2026.01_wrong Crendetials_on_Paste.xml

macOS:

11_Import_Records_ODBC/MAC/11_Import_Records_from_Odbc_MAC_2026.fmp12
11_Import_Records_ODBC/MAC/Import_Records_ODBC_Source_2026.01.xml
11_Import_Records_ODBC/MAC/Import_Records_ODBC_Result_2026.01.fmscript

Open the .fmp12 in FileMaker 2026. It holds ODBC Import steps with the credential fields left empty, and others with a user name saved. Copy them and inspect the clipboard. The _Copied_from_2026_wrong Crendetials_on_Paste pair shows what lands when a 2026 step is pasted into 2025.

The empty-credentials step comes across as “save credentials: on”

An ODBC Import step configured to not save credentials, with empty user name and password, copies like this:

<Profile QueryType="Query" flags="544" password="" UserName="" dsn="gemini" DataType="ODBC">

The flags value carries the same “Save user name and password” bit that Execute SQL uses. FileMaker 2026 leaves the step in an inconsistent state — the checkbox on, but no credentials stored — exactly as it does for Execute SQL. ai2fm flags it, on the step:

# ⚠️ You set "Save credentials" to Off, but FileMaker 2026 turned it back On and saved no credentials — this step will prompt for a user name and password when it runs.
Import Records [ With dialog: Off ; Verify SSL Certificates ; ODBC Data Source: gemini; Save credentials: Off; … ]

The saved user name is a calculation in 2026

The step with a saved user name of root copies from FileMaker 2026 with the name as a string literal:

<Profile QueryType="Query" flags="1632" password="12345678" UserName="&quot;root&quot;" dsn="gemini" DataType="ODBC">

FileMaker 2025 stores the same name as root, no quotes (Import_Records_ODBC_Source_2025.06.xml). Pasted into FileMaker 2025, the 2026 step signs in as "root", quotes included, and the import fails (Import_Records_from_ODBC_Copied_from_2026.01_wrong Crendetials_on_Paste).

ai2fm shows the name as FileMaker stored it, and converts it for the Target FileMaker Version exactly as for Execute SQL: root for 2025, "root" for 2026, a password containing a quote included. A calculation such as Get ( AccountName ) stays as it is for 2025, with the same warning:

Import Records [ With dialog: Off ; Verify SSL Certificates ; ODBC Data Source: gemini; User Name: "root"; Password: 12345678; Save credentials: On; … ]

Both platforms, the same storage

We tested this on Windows and on macOS. FileMaker 2026 writes the credentials the same way on both. The Mac capture carries the same flags="1632" and the same UserName=""root"", against a MariaDB source over ODBC:

<Profile QueryType="Query" flags="1632" password="12345678" UserName="&quot;root&quot;" dsn="mariadb" DataType="ODBC">

The point

These are the same two issues as Execute SQL, reached through a different step, because both share the ODBC connection dialog. The Save credentials flag is flipped, and ai2fm warns. The credentials are calculations in 2026 and text in 2025, and ai2fm writes them for the version you paste into. An ODBC import moves between the versions and still connects.

Reported to Claris, case 00919882 — Bug Report: FileMaker Pro Execute SQL / Import Records ODBC “Save user name and password” flag is not preserved across versions.

Bug 12 — Print PDF (step 242) — the page setup is unstable: three serializations of the same two steps disagree

The situation. Two Print PDF steps, authored identically as Landscape/Letter, saved, never edited. Read them back through FileMaker’s own three serializations and all three disagree — with each other and with what was authored. The clipboard says one thing, the SaXML another, the printed output a third.

The files we submitted to Claris

12_Print_PDF/MAC/12_Print_PDF_MAC_2026.fmp12
12_Print_PDF/MAC/Print_PDF_MAC_2026.01.fmscript
12_Print_PDF/MAC/Print_PDF_MAC_Clipboard_2026.01.xml
12_Print_PDF/MAC/Print_PDF_MAC_Clipboard_2026.02.xml
12_Print_PDF/Submitted_to_Claris/Print_PDF_Bug_Report.fmp12
12_Print_PDF/Submitted_to_Claris/Print_Pdf_Bug_ClipBoard.xml
12_Print_PDF/Submitted_to_Claris/Print_Pdf_Bug_ClipBoard_2026.02.xml
12_Print_PDF/Submitted_to_Claris/Print_Pdf_Bug_Print.txt
12_Print_PDF/Submitted_to_Claris/Print_Pdf_Bug_SaXML.xml
12_Print_PDF/WIN/12_Print_PDF_WIN_2026.fmp12
12_Print_PDF/WIN/Print_PDF_WIN_2026.01.fmscript
12_Print_PDF/WIN/Print_PDF_WIN_Clipboard_2026.01.xml
12_Print_PDF/WIN/Print_PDF_WIN_Clipboard_2026.02.xml

Open Print_PDF_Bug_Report.fmp12 and compare the three exports against each other. That is the bug.

The files that show how we protect you

12_Print_PDF/WIN/12_Print_PDF_WIN_2026.fmp12
12_Print_PDF/WIN/Print_PDF_WIN_2026.01.fmscript
12_Print_PDF/WIN/Print_PDF_WIN_Clipboard_2026.01.xml

12_Print_PDF/MAC/12_Print_PDF_MAC_2026.fmp12
12_Print_PDF/MAC/Print_PDF_MAC_2026.01.fmscript
12_Print_PDF/MAC/Print_PDF_MAC_Clipboard_2026.01.xml

Open the .fmp12, copy any Print PDF step, and read it with ai2fm. The .fmscript files are exactly what you will get.

What ai2fm does — it preserves the whole thing, byte for byte

We stopped trying to rebuild the page setup and preserved it instead. The entire driver block — the part FileMaker serializes inconsistently — is carried verbatim inside the step text:

Print PDF [ From: Source ; Restore: Adobe PDF ; Records being browsed ; All Pages ; Collate: Off ; Orientation: Portrait ; Paper size: 8.27" x 11.69" ; Scale: 65% ; With dialog: On ; PrintSettings: #blob eJzt… ]

That #blob is the complete <PrintSettings> block, compressed. On the way back into FileMaker it is restored byte-identically. Printer, paper, tray, duplex, N-up, watermark, quality, and every driver-private option we never decode — all of it returns exactly as FileMaker stored it.

The readable values in front of the blob are decoded for you and for any AI reading the script. They are information, not controls.

What ai2fm tells you — on both sides of the round-trip

Coming out of FileMaker (FM → text), every Print Setup, Print, and Print PDF step is prefixed with:

# ℹ️ The printer and page setup for this step are preserved exactly (carried in the PageFormat/PrintSettings block) and restore byte-for-byte on paste. The readable values below are for reference only — to change any print option, use FileMaker's Print Setup dialog after pasting.

Going back into FileMaker (text → FM), the same three steps are prefixed with:

# ℹ️ The original printer and page setup were preserved exactly and restored on paste, byte-for-byte. The readable values are for reference only — if you edited them they do not change the setup; change print options in FileMaker's Print Setup dialog.

Two notes, one on each side of the round-trip, on all three page-setup steps. They used to be warnings, because we could not rebuild the driver block and had to ask you to open Print Setup and print a test page. They are notes now, because we no longer rebuild anything — we carry the original bytes and give them back. What they tell you is what is true: the setup is safe, and the readable values are there to be read, not edited.

The point

FileMaker’s three serializations disagree. We no longer have to choose between them: we carry the original bytes and hand them back untouched. The instability is still FileMaker’s — the reproducer above is filed — but it can no longer cost you a print setup.

Reported to Claris, case 00918896 — Bug Report (1 of 2): FileMaker Pro 2026 Print PDF page setup is unstable/inconsistent — the Clipboard XML of the same two saved steps disagrees with SaXML, the printed output, and the authored Landscape/Letter.

Bug 13 — Print PDF (step 242), continued — a clean save fixes the clipboard, but not the SaXML or the printout

The situation. Re-save the steps cleanly and the clipboard becomes correct — both steps read Landscape/Letter as authored. The SaXML and the printed output still do not: step 0 comes out Portrait/A4 while step 1 is correct. Same file, same save, one step right and one wrong in FileMaker’s own canonical export.

The files we submitted to Claris

13_Print_PDF_2/13_Print_PDF_WIN_2.fmp12
13_Print_PDF_2/Print_PDF_WIN_2_2026.01.fmscript
13_Print_PDF_2/Print_PDF_WIN_Clipboard_2_2026.01.xml
13_Print_PDF_2/Print_PDF_WIN_Clipboard_2_2026.02.xml
13_Print_PDF_2/Submitted_to_Claris/Print_PDF_Bug_Report_2.fmp12
13_Print_PDF_2/Submitted_to_Claris/Print_Pdf_Letter_Landscape_Clipboard_2.xml
13_Print_PDF_2/Submitted_to_Claris/Print_Pdf_Letter_Landscape_Clipboard_2_2026.02.xml
13_Print_PDF_2/Submitted_to_Claris/Print_Pdf_Letter_Landscape_Print_2.txt
13_Print_PDF_2/Submitted_to_Claris/Print_Pdf_Letter_Landscape_SaXML_2.xml

The files that show how we protect you

13_Print_PDF_2/13_Print_PDF_WIN_2.fmp12
13_Print_PDF_2/Print_PDF_WIN_2_2026.01.fmscript
13_Print_PDF_2/Print_PDF_WIN_Clipboard_2_2026.01.xml
13_Print_PDF_2/Print_PDF_WIN_Clipboard_2_2026.02.xml

What ai2fm tells you — on both sides of the round-trip

Coming out of FileMaker (FM → text), every Print Setup, Print, and Print PDF step is prefixed with:

# ℹ️ The printer and page setup for this step are preserved exactly (carried in the PageFormat/PrintSettings block) and restore byte-for-byte on paste. The readable values below are for reference only — to change any print option, use FileMaker's Print Setup dialog after pasting.

Going back into FileMaker (text → FM), the same three steps are prefixed with:

# ℹ️ The original printer and page setup were preserved exactly and restored on paste, byte-for-byte. The readable values are for reference only — if you edited them they do not change the setup; change print options in FileMaker's Print Setup dialog.

Two notes, one on each side of the round-trip, on all three page-setup steps. They used to be warnings, because we could not rebuild the driver block and had to ask you to open Print Setup and print a test page. They are notes now, because we no longer rebuild anything — we carry the original bytes and give them back. What they tell you is what is true: the setup is safe, and the readable values are there to be read, not edited.

The point

This one matters beyond print. The clipboard — the source ai2fm reads — is the one that came out right after a clean save, while FileMaker’s own migration export did not. Reading the clipboard directly, and preserving its bytes, is what makes the difference here.

Reported to Claris, case 00918897 — Bug Report (2 of 2): FileMaker Pro 2026 — after a clean save the Clipboard XML is correct but SaXML and the printed output still mis-serialize one of two identical Print PDF steps (Portrait/A4 instead of the saved Landscape/Letter).

Bug 14 — Print Setup (step 42) — the same unstable page setup, and how we protect you

The situation. Print Setup carries the very same page setup through the very same driver block, and inherits the very same instability documented in Bugs 12 and 13.

The files

14_Print_Setup/WIN/14_Print_Setup_WIN_2026.fmp12
14_Print_Setup/WIN/Print_Setup_WIN_2026.01.fmscript
14_Print_Setup/WIN/Print_Setup_WIN_Clipboard_2026.01.xml
14_Print_Setup/WIN/Print_Setup_WIN_Clipboard_2026.02.xml

14_Print_Setup/MAC/14_Print_Setup_MAC_2026.fmp12
14_Print_Setup/MAC/Print_Setup_MAC_2026.01.fmscript
14_Print_Setup/MAC/Print_Setup_MAC_Clipboard_2026.01.xml
14_Print_Setup/MAC/Print_Setup_MAC_Clipboard_2026.02.xml

What ai2fm does — it preserves the whole thing, byte for byte

# WINDOWS
Print Setup [ Restore: HP LaserJet MFP M430-431 PCL-6 ; Orientation: Portrait ; Paper size: 8.5" x 13.39" ; Scale: 100% ; With dialog: Off ; PageFormat: #blob eJzt… ]

# MAC
Print Setup [ Restore: Any Printer ; Orientation: Portrait ; Paper size: 7.75" x 10.75" ; Scale: 50% ; With dialog: Off ; PageFormat: #blob eJzt… ]

The #blob is the whole <PageFormat> block, restored byte-identically on paste.

The readable values are decoded from that block. Getting them right took real work, because Windows printers do not agree on where the scale lives: Adobe and Xerox use the standard Windows field, HP keeps it in a named table of its own, and EPSON, Canon and Brother each hide it somewhere different in their private data. Zebra, OneNote and Microsoft Print to PDF have no scaling at all. Every one of those was confirmed against the printer’s own driver dialog. On Mac the values come from named keys in the print ticket, and Any Printer is a real setting — it means the page setup is not bound to a specific printer.

What ai2fm tells you — on both sides of the round-trip

Coming out of FileMaker (FM → text), every Print Setup, Print, and Print PDF step is prefixed with:

# ℹ️ The printer and page setup for this step are preserved exactly (carried in the PageFormat/PrintSettings block) and restore byte-for-byte on paste. The readable values below are for reference only — to change any print option, use FileMaker's Print Setup dialog after pasting.

Going back into FileMaker (text → FM), the same three steps are prefixed with:

# ℹ️ The original printer and page setup were preserved exactly and restored on paste, byte-for-byte. The readable values are for reference only — if you edited them they do not change the setup; change print options in FileMaker's Print Setup dialog.

Two notes, one on each side of the round-trip, on all three page-setup steps. They used to be warnings, because we could not rebuild the driver block and had to ask you to open Print Setup and print a test page. They are notes now, because we no longer rebuild anything — we carry the original bytes and give them back. What they tell you is what is true: the setup is safe, and the readable values are there to be read, not edited.

The point

We decode as much as we honestly can, and we preserve everything regardless. If a printer ever appears whose layout we do not recognise, the readable line will say less — and the setup will still come back exactly as it went in.

Bug 15 — Print (step 43) — the same unstable page setup, and how we protect you

The situation. Print carries the same page setup through the same driver block as Print Setup and Print PDF, and inherits the same instability.

The files

15_Print/WIN/15_Print_WIN_2026.fmp12
15_Print/WIN/Print_WIN_2026.01.fmscript
15_Print/WIN/Print_WIN_Clipboard_2026.01.xml
15_Print/WIN/Print_WIN_Clipboard_2026.02.xml

15_Print/MAC/15_Print_MAC_2026.fmp12
15_Print/MAC/Print_MAC_2026.01.fmscript
15_Print/MAC/Print_MAC_Clipboard_2026.01.xml
15_Print/MAC/Print_MAC_Clipboard_2026.02.xml

What ai2fm does — it preserves the whole thing, byte for byte

# WINDOWS
Print [ Restore: Brother HL-EX470 series ; Records being browsed ; All Pages ; Collate: Off ; Orientation: Portrait ; Paper size: 8.27" x 11.69" ; Scale: Fit to Paper Size ; With dialog: Off ; PrintSettings: #blob eJzt… ]

# MAC
Print [ Restore: canon ; Records being browsed ; All Pages ; Collate: On ; Scale to fit: 4x6 ; Scale down only ; With dialog: Off ; PrintSettings: #blob eJzt… ]

Print also carries what is printed — records, page range, copies, collate — and those round-trip exactly.

Scaling reads differently on the two platforms because the two dialogs are different. Windows gives a percentage, or a mode name when the driver is set to fit rather than a number. Mac’s Print dialog has no percentage here: it has Scale to Fit Paper Size with a destination paper and a Scale Down Only checkbox, and that is what we show.

What ai2fm tells you — on both sides of the round-trip

Coming out of FileMaker (FM → text), every Print Setup, Print, and Print PDF step is prefixed with:

# ℹ️ The printer and page setup for this step are preserved exactly (carried in the PageFormat/PrintSettings block) and restore byte-for-byte on paste. The readable values below are for reference only — to change any print option, use FileMaker's Print Setup dialog after pasting.

Going back into FileMaker (text → FM), the same three steps are prefixed with:

# ℹ️ The original printer and page setup were preserved exactly and restored on paste, byte-for-byte. The readable values are for reference only — if you edited them they do not change the setup; change print options in FileMaker's Print Setup dialog.

Two notes, one on each side of the round-trip, on all three page-setup steps. They used to be warnings, because we could not rebuild the driver block and had to ask you to open Print Setup and print a test page. They are notes now, because we no longer rebuild anything — we carry the original bytes and give them back. What they tell you is what is true: the setup is safe, and the readable values are there to be read, not edited.

The point

Same protection as Print Setup: everything preserved byte-for-byte, the readable part decoded as far as it honestly goes.

One more thing, on all three print steps — the dialogs misreport

FileMaker’s print dialogs display values that are not what the step stores. Three confirmed cases:

• Windows, the settings wheel — shows the last-used printer settings for every step, not the settings of the step you opened.
• Mac, page range — a step that stores Pages: 7 to 90 shows All Pages with the range boxes greyed out at 1 and 1.
• Mac, Destination Paper Size — the closed popup reads US Letter while the checkmark inside the popup, and the Paper Handling summary line above it, both correctly read 4x6. The same dialog contradicts itself on screen.

None of these is data loss. FileMaker’s own copy, paste and duplicate all keep the values, and ai2fm’s round-trip returns them byte-identically. Only the display is wrong.

So do not check a print step by opening its dialog. Expand the Paper Handling summary, or open the popup and look at which item is ticked. Both show the truth.

The bugs we found and did NOT report

Not everything we found is worth Claris’s time, and a catalogue that lists every defect regardless of consequence is less useful, not more. The next two bugs are real — FileMaker genuinely does the wrong thing — but they cannot harm a user, so we are documenting them here rather than filing them. Both are the same phenomenon:

FileMaker 2025’s clipboard leaks 2026 features it does not understand. Open a file authored in FileMaker 2026 with FileMaker 2025, copy a step, and in some cases the 2026-only data rides along into the clipboard — even though 2025 has no idea what it is. The reason is structural, and it explains why some steps leak and others do not:

• When the 2026 feature is a new value inside an element 2025 already knows, the data passes through 2025’s parser as an opaque string and lands in the clipboard — it leaks.
• When the 2026 feature is a brand-new element name — Show Custom Dialog’s window size, Save a Copy as XML’s new options — 2025 has no slot for it, correctly drops it, and the clipboard is clean.

So FileMaker 2025 is capable of doing this right, and does, most of the time. The leak is inconsistent with its own correct behaviour, which is what makes it a bug rather than a design choice.

Why we are not filing either one: nobody is affected. A 2025 user never sees the leaked data — the option does not exist in their version, the interface shows nothing, and pasting the polluted clipboard back into 2025 does nothing at all. The data is not lost either, because it is still in the file: open that same file in 2026 again and the feature is intact. The only software that ever notices is a tool like ai2fm, which reads the clipboard directly and would otherwise show a 2025 developer a control their FileMaker does not have. We handle it on our side and move on. Everything else on this page destroys or corrupts something a developer deliberately set; these two only shuffle bytes nobody will ever look at.

The two steps where we saw it — each with its own reproducer file:

Bug 16 — Set Zoom Level (step 97) — 2026’s Custom zoom leaks into the 2025 clipboard

Set Zoom Level’s Custom option is new in FileMaker 2026: it stores a zoom calculation as a new value on the existing <Zoom> element. Because <Zoom> is an element FileMaker 2025 already knows, when a 2026-authored step is copied under 2025 the Custom zoom calculation passes through 2025’s parser as an opaque string and survives into the 2025 clipboard — even though 2025 has no Custom option to show it in. A 2025 developer sees nothing (the interface offers no Custom zoom), pasting the clipboard back into 2025 does nothing, and the value is still safe in the file for when it is next opened in 2026. Only a tool reading the clipboard directly would notice the leaked calculation; ai2fm handles it on our side. Real bug, zero user impact — documented, not filed.

The files

16_Set_Zoom_Level/16_Set_Zoom_Level_2025.fmp12
16_Set_Zoom_Level/16_Set_Zoom_Level_2026.fmp12
16_Set_Zoom_Level/Set_Zoom_Level_2025_Script_Workspace_RENDERS_EMPTY_for_2026_Custom_zoom_values_MAC_22.07.png
16_Set_Zoom_Level/Set_Zoom_Level_Clipboard_2025.06.xml
16_Set_Zoom_Level/Set_Zoom_Level_Clipboard_2025.06_Pasted_from_2026.01.xml
16_Set_Zoom_Level/Set_Zoom_Level_Clipboard_2025.07.xml
16_Set_Zoom_Level/Set_Zoom_Level_Clipboard_2025.07_Pasted_from_2026.02.xml
16_Set_Zoom_Level/Set_Zoom_Level_Clipboard_2026.01.xml
16_Set_Zoom_Level/Set_Zoom_Level_Clipboard_2026.02.xml

Seen on screen (FileMaker Pro 22.07, macOS)

Every fixed zoom renders correctly — 25%, 50%, 75%, 100%, 150%, 200%, 300%, 400%, Zoom In, Zoom Out. Only the three Custom steps come through blank, highlighted below:

The value is in the 2025 clipboard — <Zoom value="ByCalculation"/> is present in the file. FileMaker 2025 simply has no interface for a feature that did not exist when it shipped, so it draws nothing. Nothing is lost: reopen the file in 2026 and the custom zoom is intact.

Bug 17 — Re-Login (step 138) — a 2026 file reference leaks into the 2025 clipboard

Re-Login’s data-source file reference is new in FileMaker 2026, and it rides in the same way: copied under FileMaker 2025, the 2026 <FileReference> data leaks into the 2025 clipboard because it travels inside structure 2025’s parser passes through opaquely. As with Set Zoom Level, the 2025 interface shows nothing, pasting back into 2025 does nothing, and the file itself is unharmed — the feature returns intact when the file is reopened in 2026. Only a direct clipboard reader sees the leak; ai2fm absorbs it. Same class, same verdict: real bug, no user impact, documented rather than reported.

The files

17_Re_Login/17_Re_Login_2025.fmp12
17_Re_Login/17_Re_Login_2026.fmp12
17_Re_Login/Re-Login_2025.06_Clipboard.xml
17_Re_Login/Re-Login_2025.06_Pasted_from_2026.01_Clipboard.xml
17_Re_Login/Re-Login_2025.07_Clipboard.xml
17_Re_Login/Re-Login_2025.07_Pasted_from_2026.02_Clipboard.xml
17_Re_Login/Re-Login_2025_Script_Workspace_SHOWS_NOTHING_though_FileReference_data_IS_in_the_clipboard_MAC_22.07.png
17_Re_Login/Re-Login_2026.01_Clipboard.xml
17_Re_Login/Re-Login_2026.02_Clipboard.xml
17_Re_Login/Re-Login_2026_Script_Workspace_SHOWS_file_target_Current_File_and_named_file_MAC_26.02.png

Seen on screen — 2026 above, 2025 below

In FileMaker 2026 every Re-Login step names its target file — Current File, or a named file such as "Import_Records_Source":

Paste the same steps into FileMaker 2025 and the target is not drawn at all — every step looks the same:

The data is still there. The <FileReference> elements are present in the 2025 clipboard — 2025 has no interface for a 2026 feature, so it shows nothing. Pasting back into 2025 does nothing, the file is unharmed, and the feature returns intact when the file is reopened in 2026.

And one more, reported: the clipboard is right and the rest is wrong

The last bug on this page belongs with the filed ones — we reported it to Claris — but it is placed here at the end because it is the odd one out. Every bug above it damages the clipboard. This one leaves the clipboard perfect and corrupts the three formats you would use to read a solution instead.

Bug 18 — Insert from Device (step 161) — the barcode types are named wrongly in SaXML, the DDR and the printout

Update, 2026-10-06 — Claris says a fix is coming. Not yet tested by ai2fm. Claris told us the wrong barcode types in the Database Design Report (HTML and XML) and in Save a Copy as XML are fixed in the latest pre-release build of FileMaker Pro, for an upcoming update. Claris did not mention the printed script. We will check all three formats when the update is public.

This one is different from everything above it. The clipboard is right. It is the three formats you would use to read a solution — the DDR, the printed script, and the SaXML that migration tooling consumes — that name the wrong barcode symbologies.

We authored one step with three barcode types ticked: Aztec, Data Matrix and GS1 DataBar Limited. FileMaker stores that selection as a bitmask, and the clipboard records it exactly:

<Barcodes types="3670016"/>

3670016 is 524288 + 1048576 + 2097152 — the bits for those three types, and nothing else.

Every other output names a different set:

Types: ITF-14, Aztec, Data Matrix

GS1 DataBar Limited is gone. ITF-14 was never selected. Every name past the eighth entry in the Barcode Options list is shifted one place, so each of the three is reported as its neighbour.

SaXML disagrees with itself

The clearest evidence needs nothing but the SaXML file:

<Parameter type="type">
    <List value="3670016">
        <name>ITF-14</name>
        <name>Aztec</name>
        <name>Data Matrix</name>
    </List>
</Parameter>

It carries the correct number and the wrong names, in the same element. You do not need our word for which is right — the value and the names contradict each other on one screen.

The files

• 18_Insert_from_Device/Insert_from_Device_Bug_Report_2026.fmp12 and ..._2025.fmp12 — open either, look at Barcode Options on the step, and you will see the three ticked boxes.
• ..._Print_Out_Bug_2026.xml and ..._2025.xml — the clipboard, types="3670016" in both.
• ..._Print_Out_Bug_2026_SaXML.xml and ..._2025_SaXML.xml — SaXML, correct value with wrong names.
• ..._Print_Out_Bug_2026_Print.fmscript and ..._2025_Print.fmscript — the printed output.
• Insert_from_Device_2026_html_DDR/ — the generated DDR.

Why it matters

A barcode step that scans the wrong symbologies is a functional problem, and this misreports one in the direction that hides it. Read the DDR and you are told the step scans ITF-14, which it does not, and never told it scans GS1 DataBar Limited, which it does. Someone auditing a solution against its own documentation would confirm the wrong answer and find nothing wrong.

SaXML is the format used by upgrade and migration tooling, so the misnaming follows a solution through migration — though the underlying number stays correct throughout, which is why the fix should be straightforward.

It only shows with a partial selection reaching past the eighth entry. Pick one type, or pick all twenty-two, and every format agrees.

Present in FileMaker Pro 2025 and 2026, identically. ai2fm reads the bitmask, so it reports the three types the developer actually chose.

Reported to Claris, case 00930742 — Bug Report: Insert from Device barcode types at SaXML, HTML DDR and printed output are named incorrectly in FileMaker Pro 2026 and 2025 — the same wrong three symbologies on both versions, while the Clipboard XML is correct

Community workaround

Takahata-san (@stbison) took the time to work through these same FileMaker 2026 clipboard bugs and write up a manual workaround — a practical option for anyone not using ai2fm. Worth a read, and our thanks for the effort:

• Silent-drop bugs in FileMaker 2026 — workaround strategy