Yes, FileMaker can write container data to disk from a server-side script. The native Data File script steps (Create Data File, Open Data File, Write to Data File, and Close Data File) have shipped with FileMaker since version 18, and Claris lists all four as supported on FileMaker Server and FileMaker Cloud. This free demo file shows the whole pattern in a form you can open, run, and copy.
Here is the moment it exists for. A nightly script on FileMaker Server is supposed to drop every signed delivery PDF into a folder your accounting system picks up in the morning. The script ran fine when someone tested it from their desk. In the morning the folder is empty, and nobody knows until accounting asks where the paperwork went.
Why is exporting container data on the server tricky?
For years the obvious tool, Export Field Contents, could not run in a server-side script. Teams worked around it with plug-ins, or by moving the export back onto someone’s desktop where a person had to remember to run it.
That changed recently. The FileMaker 2026 release notes state that Export Field Contents “is now supported in scripts run by FileMaker Server, FileMaker Data API, and the OData API.” If your host already runs FileMaker Server 2026, you have two native options. If your host runs FileMaker Server 2025 or earlier, or you are on FileMaker Cloud, where Claris still lists Export Field Contents as not supported, the Data File steps are the native route.
Even with both options available, the Data File steps give you finer control. You decide the exact path, you check for an existing file first, and you decide when the file is closed. The container field does not need to be on the layout, and no plug-in has to be installed on the server.
What the demo file does
The demo walks through one export from start to finish. Every step is a native script step, so you can read the script and copy it straight into your own solution.
A minimal version of the script looks like this. Field and table names are examples.
Set Variable [ $filepath ; Value: Get ( DocumentsPath ) & Exports::FileName ]
Get File Exists [ "$filepath" ; Target: $exists ]
If [ $exists ]
Delete File [ "$filepath" ]
End If
Create Data File [ "$filepath" ; Create folders: Off ]
Open Data File [ "$filepath" ; Target: $fileID ]
Write to Data File [ File ID: $fileID ; Data source: Exports::Document ]
Close Data File [ File ID: $fileID ]
Three details matter in production:
- Create Data File does not open the file. Claris documents that it creates an empty, closed file, so Open Data File is always the next step.
- Container data is written as binary. When the data source is a container field, Write to Data File ignores the character encoding option and writes the file as-is, so a PDF comes out as a PDF.
- Always close the file. A file left open stays locked until the script closes it or the session ends, and FileMaker allows only 25 data files open at once.
How the Data File steps compare to Export Field Contents
This table reflects the current Claris compatibility listings for each script step.
If users need to download a file in WebDirect, Export Field Contents is still the right step. For scheduled and server-side work, the Data File pattern runs everywhere your server does.
The same four steps power other Kyo tools. The Calendar Invite Creator uses them to write .ics invite files, and they pair well with the Multi-File Uploader when files come in through one door and need to go out through another.
What this could look like in your solution
Most teams start with one export and find three more. Signed delivery receipts pushed to a shared folder every night. Inspection photos written out for a customer portal. Invoices saved as PDFs where the accounting system can pick them up. A backup copy of every drawing attached to a job. Each one is the same pattern with a different path and a different container field.
Kyo Logic builds custom Claris FileMaker and manufacturing software for businesses across New England and beyond, and this demo comes from the same work: a problem our clients kept hitting. If you want help pointing the pattern at your own tables, setting up the server schedule, or deciding where exported files should live, reach out.
Frequently asked questions
Can FileMaker Server export container data?
Yes. The Data File script steps (Create Data File, Open Data File, Write to Data File, Close Data File) run on FileMaker Server and FileMaker Cloud and have been available since FileMaker 18. From FileMaker 2026, Export Field Contents also runs in server-side scripts.
Do I need a plug-in to export files from a container on the server?
No. The Data File script steps are native FileMaker script steps. The container field also does not need to be on the current layout.
Why should I close the data file after writing?
Open Data File keeps the file open until Close Data File runs or the session ends. Closing it releases the file for other processes, and FileMaker allows a maximum of 25 data files open at once.
Does this work in FileMaker WebDirect?
No. Claris lists the Data File script steps as not supported in WebDirect. For WebDirect downloads, use Export Field Contents, which sends the file to the browser.
Quick takeaways
- Check which FileMaker Server version your host runs. On 2025 or earlier, or on FileMaker Cloud, the Data File steps are the native way to export container data on the server.
- Always pair Open Data File with Close Data File, and check for an existing file before you create a new one.
- Write exports to a known folder such as Get ( DocumentsPath ) so the next system knows where to look.
- Download the demo and run the script once before you wire it into a schedule.
