3 Replies Latest reply on Oct 31, 2011 4:25 PM by philmodjunk

    Deleting Record Reverts edits to Related Record

    philmodjunk

      Summary

      Deleting Record Reverts edits to Related Record

      Product

      FileMaker Pro

      Version

      11.03

      Operating system version

      Windows 7

      Description of the issue

      If a script modifies a field in a related record, then deletes the current record, the related record reverts to previous stored values.

      Steps to reproduce the problem

      Section of script looks like this:
      Set Field [RelatedTable::Count ; RelatedTable::Count - 1]
      Delete Records [no dialog ]

      Configuration information

      I used the debugger to step through the script. I could see the value change correctly, but when I then checked the values in the related record, they were unchanged.

      Workaround

      use commit record after editing the values in the related record.
      Set Field [RelatedTable::Count ; RelatedTable::Count - 1]
      Commit Record []
      Delete Records [no dialog ]

        • 1. Re: Deleting Record Reverts edits to Related Record
          TSGal

          PhilModJunk:

          Thank you for your post.

          I am able to replicate the issue with FileMaker Pro 11.0v4 under Windows XP, Mac OS X 10.6.8 and Mac OS X 10.7.1.  I have forwarded your post along with my findings to our Development and Testing departments for additional review.

          TSGal
          FileMaker, Inc.

          • 2. Re: Deleting Record Reverts edits to Related Record
            TSGal

            PhilModJunk:

            Development is saying this is not an issue.  The reasoning is if you edit a related record but don't commit, you haven't really made a modification yet.  Since the change is made via the main record, that change is part of the main record's transaction.  Deleting the record without committing is the same as deleting the transaction without committing it.  It would be wrong to commit changes in other tables if the main record/transaction is deleted because those changes might result in the creation of orphaned child records.  Also, if FileMaker tried to commit "related changes" even though the main record/transaction was deleted, what if the user didn't want to commit the related changes?  The current behavior allows the user to click out/commit the changes and then delete the record.

            TSGal
            FileMaker, inc.

            • 3. Re: Deleting Record Reverts edits to Related Record
              philmodjunk

              Sorry, but can't agree with this statement:

              It would be wrong to commit changes in other tables if the main record/transaction is deleted because those changes might result in the creation of orphaned child records.

              That referential integrity issue is why we have the "delete records in this table when a record is deleted in the related table" option.

              Still mulling over the rest of this as the data entry is modifying a different record in a different table.

              If all relationships were of a strict Parent with primary key to Child with foreign key relationship, this would make more sense to me, but many relationships are based on more ephemeral and less strict relationships where the link between record in table A to record in table B is not the sole relationship involved and the records in the related table, in this case, are needed independently of whether or not the new record in the current layout is or is not retained.

              At the very least, this should be clearly documented in Help.