You want to change a field, but first you need to know which scripts and layouts depend on it. An XML Database Design Report, or DDR, provides a snapshot of the file’s structure for that review.
Use the field Contacts::Email as a working example, or choose a field in your own file. The aim is to build a review list—not to decide automatically that an object can be deleted.
1. Export a complete, current report.
In FileMaker Pro, open the related database files with full access. Enable Use advanced tools if needed, then choose Tools → Database Design Report. Include the relevant files, tables and element categories, select XML, and create the report. FileMaker Pro is required and sold separately.
Use the XML DDR format, not an HTML DDR or Save a Copy as XML. Those are different exports. The Claris schema documentation describes the export choices.
Keep the reports together and note when they were created. If you modify the file afterward, the earlier export will not show those changes. Reports can contain sensitive design details, so store them with your development material.
2. Load the reports together.
Open DDR Explorer, choose the database XML reports, and include Summary.xml so the tool can check for omitted files. Wait until import completes before searching.
Processing stays in your browser. The workspace does not upload or save your project and has no analytics. The ordinary Filesoft article you are reading uses the site’s aggregate page-load tracking; that is separate from the analyzer.
3. Select the field and inspect Used by.
In Objects, search for Email. Narrow the database file and object type if several objects share that name. Select the field whose table and file match your intended target.
Choose Used by for incoming references. Open each relevant result and read the surrounding definition. For example, a result might be a layout showing the field or a script that sets it. Record the object name, file and what you need to check.
Uses is the opposite direction: it shows what the selected object references. A field calculation may use other fields even when no layout displays its result.
4. Look beyond explicit references.
Switch to Any text and search for the field name or a meaningful calculation fragment. This can help you locate names embedded in SQL or dynamically constructed expressions. A text match is a lead to inspect, not proof of a dependency.
Review missing-reference findings too. An unresolved target can indicate a missing report or definition rather than a broken app. Include omitted files and reimport before drawing conclusions.
Dynamic names, Evaluate, SQL text and incomplete exports can leave gaps. External integrations may also refer to a field without being represented in the reports you imported.
5. Turn the findings into a change checklist.
- Keep a backup and make the proposed change in a working copy.
- Review the affected layouts, calculations, scripts and integrations from your list.
- Exercise the relevant workflows with the intended access privileges and target platforms.
- Export a new DDR after the change and repeat the searches.
You can export reference results as CSV to keep alongside your notes. Clear project when finished; downloaded CSVs and clipboard copies remain under your control.
Start on a desktop browser. Read the current compatibility and limits before loading a large or unfamiliar DDR. Browser analysis does not replace testing in FileMaker.
PUT IT INTO PRACTICE
Try it with Filesoft.
Open the DDR Explorer guideWant a guided learning path? Explore the free FileMaker courses.
Continue reading
Reference: Documenting database schemas. Examples are learning aids; check them in your own FileMaker working copy.