Search the Community
Showing results for tags 'magic-key'.
Found 1 result
I'm having an issue with and offline sync setup that I created. I used the basic outline as described in the FM white paper for offline syncing. I'm using a transactional model for the whole sync process, so there is a final commit at the end if things don't throw an error. It is this final commit that is currently giving me problems. When this commit fires, all of the records that were created during the sync process are once again tagged as being 'modified', and so the modification timestamps are updating again. Here's an example: say I sync 3 records at 22:43. During the sync process the modification time stamps for these 3 new records, reflected at the destination, are: 1: 15:00 2: 13:24 3: 18:31 That's as it should be. But then at the end of the process, when the final commit happens, the three records change: 1: 18:31 2: 18:31 3: 18:31This sync process has a modification override feature, such that when a record is recreated at the destination it will still show the modification TS from when it was created/edited at the source, not when it was copied to the destination (the server). The FM white paper does this with a 'modification_TS' override field. So I have two mod_TS fields: 1 is a standard 'last record modification TS' called "zModTS_Always", and the other is "ModTS_Useful" field that is supposed to reflect the timestamp the record was modified by the user, and not the one where it was modified by the sync process. This override field is used only during the sync process. It is defined thusly: If( zModTS_Always and Sync::ModOverride_g ; Sync::ModOverride_g ; zModTS_Always ) This is important because you don't want the modification time to be changing whenever someone syncs - this would cause all kinds of re-syncing between users. My problem is that the final commit at the end of the sync process is causing all the records that were just created at the destination to have their 'Useful' timestamp updated one last time, and set equal to the 'useful' time stamp of the last record sync'ed. It isn't the timestamp at the point of the sync itself, the override field is still functioning as expected, it is just being fired for records that are not the current record. This might not be too much of a problem...at least the times are something prior to the sync time. But I am sorting a portal of these records based on this timestamp, and having them all with the same timestamp makes the sort rather useless. Or if I were to commit each record after it was created, that would probably solve the problem - but that eliminates the transactional benefits. So I'm just not certain what is causing all these records to be modified one final time when the commit is done. Anyone familiar with maintaining modification timestamps using a transactional technique? Thanks, Justin PS. Lee, sorry if this is in the wrong place; I didn't see any other sub-forums anymore, just the 14/13/Older general discussions.