Dry runs and batch behavior

filemaker runs a batch as one transaction. A successful regular run commits at the end; a successful dry run performs the same work but discards the changes instead. By default, any operation error aborts the batch and rolls back every earlier change.

Batch lifecycle

filemaker opens the file once, processes the NDJSON operations in line order, and finishes with either a commit or an abort.

• If every operation succeeds, a regular run commits the batch.

• If any operation fails, the default behavior is to abort and roll back the whole batch.

• If --dry-run is present, filemaker discards the batch instead of committing it.

Each operation still produces a result line. The closing summary reports the totals, whether the run was a dry run, and whether the batch rolled back. Treat the summary as the outcome for the entire batch; an earlier operation's successful result does not mean it survived a later error.

Dry runs

Add --dry-run to test a batch without keeping its changes:

filemaker --file="/absolute/path/Contacts.fmp12" \
  --dry-run \
  create-invoices.ndjson

A dry run uses the same file, operations, validation, and transaction behavior as a regular run. The difference comes at the end: instead of committing a successful batch, filemaker throws away its changes.

If an operation fails, a dry run reports the same error that a regular run would encounter and aborts the batch. This makes dry runs useful for testing, but they are optional rather than a required step before every change.

Note  A dry run is a point-in-time test A successful dry run shows that the batch could run against the file in its current state. Another user or process can change the file before the regular run, so a later commit can still fail.

Errors and rollback

With the default --abort-on-error=true, an error prevents a partial schema change. For this batch:

{"op":"create:table","name":"Invoices"}
{"op":"create:table","name":"Invoices"}

the first operation can report success, then the second reports table_exists. The closing summary reports an error and "rolledBack":true, and the first table creation is not committed.

Do not retry an entire operations file without checking the final summary and the current file state. Operations files are temporary batch input, not migrations that you can safely replay.

Allow partial success

Passing --abort-on-error=false changes the default transaction policy. filemaker continues after an operation error and commits the operations that succeeded:

filemaker --file="/absolute/path/Contacts.fmp12" \
  --abort-on-error=false \
  operations.ndjson

Use this only when partial application is acceptable. For schema changes that depend on one another, keep the default all-or-nothing behavior.