Script versioning strategy in FileMaker solutions

Expert

Track script changes across deployments using version fields, a change log table, and a disciplined update workflow that avoids breaking production.

What you'll learn

How to implement a schema version field in your solution
How to maintain a script changelog table
How to export scripts to XML as a pre-deployment snapshot
How to name deprecated scripts so callers fail loudly rather than silently
How to communicate breaking script changes to callers

FileMaker has no built-in version control for scripts. Once you overwrite a script, the previous version is gone unless you have an external backup. A versioning strategy -- a combination of naming conventions, a changelog table, export snapshots, and deployment discipline -- gives you the traceability needed to diagnose regressions and roll back safely.

1/3

Maintain a solution version record

Create a Preferences or Settings table with a single record that holds the current solution version (e.g., "2.4.1"), the last deployment date, and a text field for release notes. An OnFirstWindowOpen script checks this version and can display a "What's new" dialog when the version changes.

FileMaker Script

# Script: On First Window Open
Set Variable [ $currentVersion ; Value: "2.4.1" ]
Set Variable [ $storedVersion ; Value: Settings::SolutionVersion ]

If [ $storedVersion != $currentVersion ]
  # New version deployed -- show release notes
  Show Custom Dialog [
    Title: "Updated to version " & $currentVersion ;
    Message: Settings::ReleaseNotes
  ]
  Set Field [ Settings::SolutionVersion ; $currentVersion ]
  Set Field [ Settings::LastDeployedDate ; Get ( CurrentDate ) ]
  Commit Records/Requests [ No dialog: On ]
End If

Modular script libraries in FileMaker Performance profiling FileMaker scripts