Commit causes 'modification' TS to fire, after creating multiple records with magic-key?

[Justin Close]

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:31

This 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.

Edited October 13, 2015 by Justin Close

[Lee Smith]

I don’t know where this belongs either, I know it doesn’tb belong in the General Topics because they are reserved for the discussion of the FileMaker tools functions and features that were new in that particular release of FileMaker.

 Are you talking about FileMaker go, FileMaker server,  360s plug-ins, or some other means of syncing.

 I’m going to move this topic to scripts unless one of the other topic areas fit the bill better.

[Justin Close]

Hmmm...maybe the page wasn't loading fully for me when I was starting it, because I didn't see all the various sub-forums lower down the page that I was expecting.  It was just the first block, the 'FileMaker Platform' group, which is the 'General', 'Web Direct', and 'iPhone/iPad'.

This specific instance is a FMGo deployed file synching to FMServer, but it seems that this issue with the modification time stamps being updated in an entire transactional block could happen in many different configurations.  Not that I have tested that...

This is one of those things that seems to cover so many aspects. 

 

[Lee Smith]

That’s why we have so many topic areas.

Even though your question could fit in a few different topics it  seems  to be more of a FileMaker go question.

 Sometimes my browser doesn’t refresh the whole page too.