Save a self-contained copy incorrectly updates modification auto-entry fields
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.
Modification timestamps would all be prior to when the self-contained copy was made.
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.