When I click on “31” under the Tables header, I am taken to this:

Each column contains a helpful link to take you to its details. It is an HTML page that includes a long barely-formatted table of all the components of the DDR. Any use of these files (opening, importing) starts at the Summary file. When I click on Create, FileMaker produces a Summary file and a file for each FileMaker file included in the report. File Handling: I rarely immediately open the file, especially if I’m using the XML format.Both are valid and useful, but the XML is MUCH more useful than the HTML format. Report Format: This choice describes the kind of output you want.Again, it seems worth it to leave all these checked except for rare circumstances. Include in Report: The middle box lists what to include in the report.

Of course it depends on the size of the file if your goal is to see only where one field in one table is used, you can only select that table. This might come in handy, but I’ve rarely done this.

Include Fields from Tables: The top-right box allows us to deselect some tables we don’t want included in the DDR.

Just make sure each file is open before running the DDR. With a multi-file solution, however, you’ll want all those included in the DDR. Those files checked will combine into one DDR, so make sure there’s no extraneous ones lurking about.

Available Files: These are all the files you have currently open.

The dialog that comes up is fairly simple. Here is where the Database Design Report is found. Start at the beginning.įileMaker Pro Advanced users have access to an additional menu: Tools So remember this: you can find any part of your custom app using the DDR.

Check the accounts that use the “EditOnly” privilege set.

Review the themes used and local styles.

Read a script outside of the script workspace.

This includes commented-out script steps or calculations, etc.

Discover unreferenced fields or scripts/layouts that aren’t called from anywhere.

Find out where the field “zz_AccountName_g” is used throughout the system: what layouts it is on, what scripts use it, and any calculations (field definitions, conditional formatting, hide-conditions, etc.) that rely on the value.

People use the DDR to do any of the following: The DDR gives us the ability to find any part of our custom app. This exposure is essential for a developer’s sanity, efficiency in tracking down issues, and lean & well-organized custom apps. After running a DDR and processing it in some way, I can find the exact places the field “zz_AccountName_g” are used (if any).

The FileMaker Database Design Report is meant to expose the DNA of a custom app, clearly identifying the locations and uses of fields, calculations, layouts, themes & styles, scripts, and other pieces. The FileMaker Database Design Report helps us to find that which we forgot. I might have created a field called “zz_AccountName_g” and used it throughout, but months later, I cannot remember where I used it or even if I ever used it in a script or on a layout or in an privilege set. But as the custom app grows in functionality, data-storage, user-interfaces, it is easy to lose track of some part of it. The web these pieces creates starts simple in the first stages of development and we may even be able to keep it all in our heads. Every custom app we build is a complex DNA strand of tables, fields, layout object and scripts, security privilege sets, conditional formatting, data-formatting options, relationships, calculations, indirection sources, and other attributes.

Filemaker pro advanced format