Modified Timestamp Changing

[Kaiviti57]

This may not be related to MirrorSync but I have not been able to identify any other reason.  MirrorSync will update records that have a changed modification timestamp.  I have a table that over 800 records in it and when I performed a sync this afternoon it took for ever to complete.  This is not the first time has happened and it is not just to this table.  After checking the sync I found that 248 of the 818 records had been modified.  The account name for the modification on all the records was mine.  Now, there is absolutely no way that I modified any of these records.  As I mentioned earlier, this is happening to several tables.  I have tried to isolate this problem by running all the scripts I can and performing a sync between each one.  The problem did not replicate.

Does anyone have any idea what might be causing this?

[Jesse Barnum]

It sounds like the result of resolving a conflict. What do you have your conflict resolution settings set to? It's probably user picks or most recent wins. If it's most recent wins, it might be a good idea to switch it to user picks, so that you (or your users) will at least know when conflicts are being resolved.

Also, on your sync layouts, you should have a single modification timestamp field, but other than that, make sure to remove any other fields that are automatically updated when a record is modified. Examples include 'modified by', or additional modification timestamps (for example, if you have both a regular modification timestamp and a host modification timestamp), or a modification date / time (as opposed to a timestamp).

[fishtech]

This is interesting.

All my sync layouts have a modification timestamp. But each layout also has 'modificationDate', 'modificationAccountName' and 'modificationUserName'.

Is this bad practice? I assumed I would need those fields to track who/when fields were modified.

thanks,

ft.

 

[Jesse Barnum]

Those fields should be removed from the sync layout.

FileMaker does not allow us to set the modification date, modification account name, or modification username - if we try to set those values (either by script or by xDBC), FM will ignore what we set, and just set the current date / account name / username. You can observe this yourself by trying to manually set them to something else - it's impossible to do, short of temporarily disabling auto-entry options, or doing an import with auto-entry options disabled.

Having established that it does no good to include those on the sync layout, let's talk about the downside of including them - the problem is that it causes field-level conflict merging to fail. Without those fields on the layout, if you change the first name of a contact record, while I change the last name of the same record, and we both sync, then MS is smart enough to see that it should merge your first name change and my last name change. However, if there is a modification username field that it's also trying to sync, it's always going to look like you and I both changed that same field on the same record - preventing MS from being able to merge those changes, and forcing it to treat it like a full-blown conflict, which must be resolved according to the conflict resolution setting for that configuration.

Therefore, since it does no good to include them on the sync layout, and it prevents MS from being able to do field-level conflict merging, I highly recommend removing them from the layout. Note that it's fine to keep those fields in the table - just not on the sync layout. That way, MS won't know about them and will not attempt to write anything to them, but FileMaker will still keep them up to date.

[Kaiviti57]

Hi Jesse,

This file is set to most recent change wins.  I do not want to leave this user user decides because that would cause huge problems.  The records in this table are very rarely changed.  In fact, in the past three years I am the only one that has changed anything and it was to maybe three records only.  The modification timestamp on nearly all the records should be the same as the creation timestamp. The other thing I can't figure out is if 248 records were modified, why weren't the rest?

The 248 records that were modified was done over a 3min 48 second period and this was done during the sync which took 15 minutes to perform.  All the 248 records contain jpegs and this slowed the sync down dramatically.   I never changed anything in these records and it was all done in the period that the sync was being performed.  It is impossible to make changes to 248 in less than 4 minutes - except via a script.

These are the auto create fields that I have on each sync table relating to creation and modification.  The mod time stamp is the only field that updates when a record is modified.

This is most baffling.

Hi Jesse,

 

I have attached my configuration file if it helps.

PIMS v5 MirrorSync Configuration.txt

[Jesse Barnum]

Try removing the zz_account_create field from the sync layout (be sure to run through the configuration and re-copy script steps after doing this), then see if the problem persists.

I don't know what caused those 248 records to be modified in the first place. You can take a look at the MirrorSync audit log records (in the 360Works/applications/logs directory) to see when those records were first written by MirrorSync.

[Kaiviti57]

I need a bit of clarity on this.  If I remove that field from the sunc layout, will it sync?   The zz_account_create field is an important part of my scripts.  If that field is not synced, I will not be able to do any remote trouble shooting.

[Jesse Barnum]

If the zz_account_create field is truly a creation auto-enter option, as opposed to a modification auto-enter option, then I think it's fine to leave it, and it will do no good to remove it. I was recommending to remove it just as a troubleshooting temporary mechanism to see if it made a difference.

In a previous post you mentioned that "each layout also has 'modificationDate', 'modificationAccountName' and 'modificationUserName'" - if that is the case, that could definitely cause the problem that you're seeing.

[Kaiviti57]

Thanks Jesse.  Actually, it was fishtech that posted that he had 'modificationDate', 'modificationAccountName' and 'modificationUserName' fields.  I only have the modification timestamp filed.

I have changed the mirrorsync configuration for conflict resolution.  I now get an email when my users have a conflict.  I am resolving it from my copy - which I know is good and in time all the conflicts will be resolved.  There has been plenty conflicts so far.

The puzzling part is that the records are being modified.  Yet nothing has been changed in the records by any of the users.  This is what I can't figure out.

[pfry]

Hello,

I have the same issue : I have a single modification timestamp field on my sync layout but the sync process change the modification timestamp ...

Any idea ?

[pfry]

I just make a try with a sync layout with only three fields : Primary key / Creation timestamp / Modification timestamp

I am still having the same issue, the Modification timestamp change during the sync process.

[pfry]

OK it is my fault 😂

I upload an sync offline file on the HUB, and I just forgot to delete the mirrorsync records before.

This is why the sync results was so strange.