4 Replies Latest reply on Sep 24, 2012 2:31 PM by disabled_ntaylor

    Save a self-contained copy incorrectly updates modification auto-entry fields



      Save a self-contained copy incorrectly updates modification auto-entry fields


      FileMaker Pro



      Operating system version

      Mac OS X 10.6.8

      Description of the issue

      Saving a self-contained copy of a database in FileMaker causes all records that have container fields to be treated as if they have been modified. This destroys all information about who and when a record was last modified by.

      This only affects records that actually have container data in them, which mitigates the problem to some extent but in some ways is worse because it's inconsistent, and from a user's standpoint, somewhat arbitrary.

      In our case, we use the record timestamps for synchronization functions. This bug leads to us re-synchronizing all records that have container data, which is the worst kind of data to resynchronize because it's big and slow.

      Steps to reproduce the problem

      Start with a database that has external container fields and a modification timestamp, both in the same table. Ideally, some records should have container data and some should not.

      Save a self-contained copy of the database.

      Open the database copy and check the modification timestamp field.

      Expected result

      Modification timestamps would all be prior to when the self-contained copy was made.

      Actual result

      Modification timestamps are set the date and time of when the copy was made, for records that have container data. Records with no container data are not affected.

      Although I have not tested it, I assume that the modification account name is also affected, as well as the Get( RecordModificationCount ) function.


      Modify the database schema prior to saving the self-contained copy, and disable all modification auto-entry options. Save the self-contained copy, then restore all modification auto-entry options in the copy.

      This is not a great workaround in my opinion, especially because we have a lot of users using our synchronization software, and there may be many modification auto-entry fields spread throughout an entire solution.