FileMaker Clipboard Bugs — verified, with reproducible test files

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

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 seventeen 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.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.

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

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 — 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

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 — 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 — 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.

Reported to Claris — 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 — 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 — 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

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.

The fix belongs to WinSoft: add the missing value-to-name entries for the dictionaries they ship beyond the standard thirteen. The 1–13 table is already correct.

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: 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) — two ways FileMaker 2026 breaks an ODBC connection

The bug. An Execute SQL step that connects to an ODBC data source has two settings FileMaker 2026 mishandles: the Save credentials checkbox and the user name. Both are corrupted the moment you save the step in 2026, and the damage travels with the step wherever you paste it. ai2fm cannot undo what FileMaker already wrote — but it can tell you, on the exact step, what happened and what to fix.

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

Bug 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 ]

Bug two — FileMaker 2026 wraps the user name in stray quotes

Now the step with a saved user name. You typed root. Copy the step, and the clipboard has this:

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

The user name is stored as "root" — with literal double quotes wrapped around it. FileMaker 2026 added them at save time. In FileMaker 2026 the step still runs, because 2026 accepts its own quoted name. But paste it into FileMaker 2025 and the step silently will not run — 2025 does not recognise "root" as a user name, the connection fails, and nothing on screen tells you why. The step is there, it displays, its values look present — it just does not work. The fix is to remove the quotes so the name reads root again.

ai2fm flags this too, and shows you the corrected name:

# ⚠️ The ODBC User Name has stray quotes added by FileMaker 2026 — remove them so it reads root or the step will not run in 2025.
Execute SQL [ With dialog: Off ; ODBC Data Source: gemini ; User Name: "root" ; Password: 12345678 ; Save credentials: On ]

The point

Both problems are FileMaker 2026’s, and both are written into the step before any tool sees it — ai2fm cannot silently repair a value FileMaker deliberately wrote. What it does instead is refuse to let either pass unnoticed: it warns you on the exact step, in plain terms, that the credential flag was flipped against your choice and that the quoted user name will break the step in 2025. A silent failure becomes a caught one.

Reported to Claris — 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 bugs, documented next.)

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

The bug. Import Records can pull its rows from an ODBC data source, using the exact same connection settings as Execute SQL — and it inherits the exact same two FileMaker 2026 problems. The Save credentials flag is set on with nothing to save, and the user name is wrapped in stray quotes. If you migrate 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 wrapped in stray quotes

And the step with a saved user name of root copies with the quotes baked in:

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

"root" — the same corruption as Execute SQL. The import runs in FileMaker 2026 but silently will not run once pasted into FileMaker 2025, until the quotes are removed. ai2fm shows you the corrected name:

# ⚠️ The ODBC User Name has stray quotes added by FileMaker 2026 — remove them so it reads root or the step will not run in 2025.
Import Records [ With dialog: Off ; Verify SSL Certificates ; ODBC Data Source: gemini; User Name: "root"; Password: 12345678; Save credentials: On; … ]

Both platforms, the same corruption

We tested this on Windows and on macOS. The clipboard is corrupted the same way on both — the Mac capture carries the identical flags="1632" and the identical UserName=""root"", against a MariaDB source over ODBC:

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

ai2fm warns on both, on every affected step. This is not a Windows quirk to be worked around on one platform — it is how FileMaker 2026 writes an ODBC step’s credentials, wherever you run it.

The point

This is the same pair of FileMaker 2026 bugs as Execute SQL, reached through a different step — because both share the ODBC connection dialog. Whether you query a database with Execute SQL or pull rows from it with Import Records, the credential flag is flipped and the user name is quote-wrapped in the same way, and ai2fm warns you the same way on both. A migrated import that would silently fail becomes one you can see and fix.

Reported to Claris — 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 — 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 — 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.

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