Review a FileMaker script before changing it.

1. Record what the script promises.

Open the script in a working copy and describe its inputs, outputs and assumptions. A useful note is short enough to review beside the script:

Script: Contact | Save follow-up
Input: contactId and note text
Entry context: contact workflow
Success: returns a documented result with the new note ID
Failure: returns a documented error; no success message
Side effects: creates a note; may change layout or found set
Review: privileges, record locks, commit errors, cancellation

This is a checklist, not a claim about a supplied script. Fill it with the actual behavior you observe. Include whether the script restores its starting layout, whether it expects a committed record, and whether it runs with full access privileges.

2. Export a fresh, complete XML DDR.

Use FileMaker Pro’s Database Design Report with the relevant files open and the necessary access. Include scripts and their related objects, then choose XML. Keep Summary.xml with the database reports and note the export time.

Load the reports together in DDR Explorer. This is the XML DDR export, not Save a Copy as XML. Review the tool’s compatibility and limits if the import is incomplete or unusually large. FileMaker Pro is required for the native export and is sold separately.

3. Follow both directions.

Find the script in Objects, checking its file if several scripts share a name. Start with Used by: inspect explicit incoming references. Which callers pass a parameter? Which read a script result? Which depend on a changed layout or current record?

Then inspect Uses: review the fields, layouts and other scripts referenced by the selected script. A helper’s failure or changed return value can affect your proposed edit even if you are not changing that helper.

Keep a small list containing the caller, the reason it matters and the workflow to test. Export reference results as CSV if useful, then add your human review notes separately.

4. Investigate what the report cannot prove.

Search Any text for the script name and distinctive parameter keys. Inspect names constructed by calculations, scripts selected dynamically, scheduled jobs and external launchers. A text match is a lead; it does not necessarily represent an executable reference.

An empty result is not proof that a script is unused. Missing reports, dynamic calls and external integrations can leave gaps. Resolve omitted files and inspect unresolved references before using them as evidence of a defect.

DDR Explorer analyzes an exported snapshot in your browser. It does not run the script, verify a record commit or establish what an account can do in a live session. Its workspace has no analytics and does not upload or save the project.

5. Test the change against the contract.

Preserve a backup and apply the edit to a working copy. For this follow-up example, use the following review cases:

• A valid contact and note: one note is created and the expected ID is returned.
• A missing or invalid contact ID: no orphan note is created.
• A blank note or cancelled action: the documented outcome is returned.
• Restricted privileges or a locked record: the script reports failure without pretending to save.
• Each important caller: parameters and result handling still match.
• The intended desktop, Go or WebDirect workflow: context and navigation remain appropriate.

Record expected and actual results rather than just “tested.” After saving the final change, export a new DDR and compare the affected references. Keep runtime results separate from the structural report: both are useful, but they answer different questions.

Continue reading

• Find where a FileMaker field is used