1 Reply Latest reply on Feb 13, 2012 9:57 PM by philmodjunk

    Referential Integrity / Cascade Changes



      Referential Integrity / Cascade Changes


      I'm working on a DB for doors. Tables include Location, Materials, Frame, GeneralInfo and many other related tables. I'm converting from a Paradox database and had many and one-to-one relationships with referential integrity and cascading changes. Being new to FMP, I'm trying to figure out how to "cascade" a field. E.g. = door number 21A has a name change to door # 21B.  I need related tables to automatically update and stay in sync so they won't get orphaned. I'm not a pro but I had good luck with Pdox (while it lasted). Any help is appreciated.  Thanks.

        • 1. Re: Referential Integrity / Cascade Changes

          FileMaker does not have such a cascading update. The only thing close is for cascading deletes when defined in FileMaker relationships.

          I've used cascading updates in MS Access so I'm familiar with the concept. I used to think it was a significant advantage over FileMaker until I observed the significant delays when a change in a field in one record triggered large number of updates that rippled through the tables in the database.

          In FileMaker (and I did it the same way in Access once I learned better), I design my tables so that cascading updates are not needed as this requires redundant data that should only be present in one record in one table in the first place. Using your dorr number example, you would not use the door number in the relationship. Use an internally generated serial number instead, with the door number only stored in a field in the parent table. Other layouts based on child tables that need to display the door number can do so simply by placing the door number from the parent record on the child table's layout.