Relationship Graph Refactoring
BeginnerSafely restructure a tangled FileMaker relationship graph -- merging redundant TOs, applying anchor-buoy, and removing obsolete connections -- without breaking layouts or scripts.
What you'll learn
- How to audit the relationship graph for redundancy and dead TOs
- How to merge redundant TOs safely
- How to reorganize to anchor-buoy without breaking field references
- How to test after each refactoring step
Every long-lived FileMaker solution accumulates graph debt: duplicate TOs, TOs left over from deleted features, circular connections that made sense at the time, and naming that no one remembers the rationale for. Refactoring the graph improves performance, reduces maintenance confusion, and prepares the solution for new features. The key is doing it safely without breaking things.
Audit: finding duplicate and unused TOs
Open the relationship graph and look for TOs with no connections (orphans), TOs that duplicate another TO's table and relationship definition, and TOs named in a way that suggests they are remnants.
// Audit checklist: // 1. TOs with no relationship lines = orphan; safe to delete // 2. Two TOs of the same base table with identical relationship predicates = duplicate // 3. TOs named with "_OLD", "_BACKUP", "_UNUSED" = deletion candidates // 4. TOs on no layouts (verify via DDR or manual search) = likely safe to delete // 5. TOs referenced only from deleted scripts = safe to delete // Tool: FileMaker's built-in "Show all related tables" highlights orphans. // Or: use the DDR (Designer Reference) XML to audit TO usage programmatically.
Sign in to track your progress and pick up where you left off.
Sign in to FM Dojo