4 Replies Latest reply on Oct 13, 2015 9:26 AM by justinc

    Off line sync - transactional: all timestamps the same after commit?


      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.


      The FM white paper talks about using a 'modification_TS' override field in order to maintain the proper time stamps on records when they are created on the other side.  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.  It is defined thusly: 

              If( zModTS_Always and Sync::ModOverride_g ; Sync::ModOverride_g ; zModTS_Always )


      So if the override field is defined (which only happens during the sync process), it will use that override TS as the entry for the ModTS_Useful, otherwise it uses the regular zModTS_Always field (the 'Always' one) as the timestamp.  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 sync'ed to have a timestamp 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.


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


      Anyone familiar with maintaining modification timestamps using a transactional technique?




        • 1. Re: Off line sync - transactional: all timestamps the same after commit?

          Field auto enter option "modified" is applied for sync process also, so you can't use "set field" or other steps.


          For workaround, I know 2 ways

          1) use import without apply options

          2) don't use "modified" field option, instead auto enter calculation with some conditions, for example

          Case ( $syncing ; Self ; Get ( CurrentHostTimestamp ) )

          • 2. Re: Off line sync - transactional: all timestamps the same after commit?

            To clarify, the 'Always' TS field does use the built-in 'last modification TS' definition in the AE calcs.  But the 'Useful' TS field uses a general AE 'calculation' to enter the time.  The calculation for this field is as noted in my posting.  It seems very similar to what you are suggesting.

            • 3. Re: Off line sync - transactional: all timestamps the same after commit?

              1) Your overriding field seems global


              then all records become same value.


              2) Your calculation always replace value, try one of 2 in case result as "Self" function.

              • 4. Re: Off line sync - transactional: all timestamps the same after commit?

                RE #1)  Yes, it is global.  It needs to be referenced from a 2 different contexts (the 'set' of the field, then the 'read' of the field).  Not that it couldn't be done with non-global field, but this just makes it easier.

                      It is only used during the sync process itself in an attempt to stop the 'auto modification' timestamp from updating during that sync process.  So the sync script sets the override field, and thus changes made to the record during the process then read the original TS and not the current TS.

                      But the records should only be changed/updated one at a time, or so I thought.  There is something going on in the commit that is causing all the records that were imported to be 'modified' yet again, and so yes, they all update to the same TS.  I'm not sure what is triggering them to be modified yet again, though.  The AE calcs should have already all fired.


                RE #2)  Yes, I do want it to always replace; it should either be a new TS or the Override TS.


                Back to your earlier message about an import process - I can't change the underlying technique, now, and I'm not sure I would want to.  The transactional technique has quite a few benefits, even if it has its quirks to work around.


                -- Justin