Syncing after importing records

[mdavis6537]

Hello,

I am using MirrorSync 3 with about 10 iPads. On the iPad solution, I have an update script that installs a new version of the file. As part of that process, all records are exported from the old file, and imported into the new file. What is happening is that after I release an update, MirrorSync on the iPad is deleting all the records and then inserting them all again after this update process is completed. I am assuming that something I am doing during the update process is confusing mirrorsync and it just decides to delete everything and re add it. 

Here is the process my update script goes through:

• Old file: Go to every layout and "SHOW ALL RECORDS", then "UNSORT RECORDS"
• New File: go to every layout and DELETE ALL RECORDS (just in case)
• Then, go to each layout and IMPORT RECORDS
• Then I sort the records, go to the last record to get the primary key, and SET NEXT SERIAL VALUE to the next value after this key.
• (I am currently not unsorting after this, maybe I should be?)
• Thats pretty much it. From there I delete the old file and start the sync, and everything gets deleted and re-inserted into the new file despite my attempt to prevent that by importing all the data.

 

Is there anything I am doing that MirrorSync might not like and would cause it to completed re-insert all the records in all the tables?

Edited June 23, 2017 by mdavis6537

[Tsiry360Works]

When you do the import, be sure to uncheck the box that says "Perform auto-enter options while importing". The primary keys, modification timestamps, and creation timestamps need to match between the mobile file and the server file. Please check the below link out for more information about offline pre-population.

http://docs.360works.com/index.php/MirrorSync_advanced_topics#Can_I_pre-populate_my_offline_database_to_speed_up_initial_sync.3F

Thanks

[mdavis6537]

Thanks Tsiry,

 

Its seems this step is the one I am not doing:

• After the import, create a new record in the MirrorSync table on the hosted database. Set the type to 'Server'. Modify the sync4 field (you'll need to switch to layout mode to see which one that is), and set it to the timestamp when you ran the import, using the format 'YYYY-MM-DD hh:mm:ss' (in 24 hour time). Note: If you are not syncing with FileMaker Server (ex. MySQL<->FileMakerPro/Go) you will make this change in the offline file.

However, that is going to prove difficult. The import into the offline file is dependent on when the user downloads the update. I wont have any idea when they did the import, and it will be different for each user. I could run a script on the server to create this new record, but it seems like that might cause problems. I guess I dont know enough about what is happening in this particular process to know what to do - can you shed any more light on it?

[Tsiry360Works]

What you can do is, create first the new record with type = 'Server' on the hosted offline file. When the user downloads the file, it will have that record already. Next, proceed with the import then update sync4 field on the offline file.

Thanks. 

[Jesse Barnum]

Mike, I want to elaborate on what Tsiry said.

We are assuming that this import process is done manually by the database administrator, and that the server record in the hosted mobile file would be created at the time that manual process is done.

As an example, let's say that you did it today, Thursday June 29th at 1:00 PM. Users who download a copy of that hosted mobile file one hour from now at 2 PM will have a fast initial sync, because only changes from the last hour will need to be compared (plus a 24 hour overlap period that we always add to account for time zones). Users who download a copy of the database in one week at 1:00 PM will still have a fairly fast sync, because they will only need to sync changes for a 7 day (+24 hour overlap) period. However, after a few months, the initial syncs will get slower and slower (depending on the amount of changes per day), as the initial sync will need to process an increasing amount of changes. Therefore, you might want to re-do this process every week, month, 3 months, or whatever makes sense for the size of your database. This can either be done manually or automated with a script, as long as the time stamp is correctly set in the MirrorSync record where the type = 'Server'.

[mdavis6537]

Thanks for the replies. I follow what you are saying but currently I am doing my updates a bit differently using a blank (no records) file distributed to the users instead of having them download the hosted mobile file. We only keep 30 days worth of records on the iPad, so I am not sure its a huge deal if it has to go back and check all the records. Perhaps I need to change my approach but this is how I do updates today.

• I work on the updates to the new offline file for the iPads on my desktop. When its ready to deploy, I delete all the records in it so its completely blank.
• I send it out to all the iPads through mobile device management, and once they get it and sync, an script runs that imports all the records from their old current file and puts them in the new file, then deleting the old one. 

So since users are not starting out by downloading the hosted mobile file, I am not sure that setting the mirrorsync record would help. Whats happening is they do the update and then mirrorsync deletes all their records that were imported and re-downloads them from the server. Perhaps if I copied over their MirrorSync record when doing the update that would prevent that from happening instead of starting with it blank?

 

Edited June 30, 2017 by mdavis6537

[Jesse Barnum]

Hi Mike, I think I understand now better what you're asking.

When you do the import into the empty clone, could you also import the records from the MirrorSync table? I think that would solve the problem, because then it would look to MirrorSync that it's still the same device and file, and it would not do the initial sync step at all.

One important thing to note - if you do this, MAKE SURE that you import ALL the records from the old file into the new empty one. If you skip some, then it will look to MirrorSync as if those records were deleted on the client, and it will then delete them on the server (assuming you're doing bidirectional syncing).