Hi All,

In the process of rolling out our solution under the Filemaker SDK so it will appear more like a "native" iOS app. One of the things I want to include this time around is a way for our users to update the app. Currently looking at this process which basically adds another filemaker file, exports all the records from the old file to the new one, and then deletes the old file. 

 

My question is: If I use this process, what do I need to be aware of with MirrorSync to make sure that I dont run into any sync issues? All the timestamp data would be transferred. But I am not sure about whether the "next primary key to be used" will transfer over, I may have to script that. Is there anything else I need to make sure transfers over, or any other potential issues to be wary of?

 

Thanks.

I have not given a lot of thought to the particular technique described in the article. I think it will probably work, although obviously you should do a lot of testing. One potential concern is that the internal record IDs will probably change when you import the data into a new file. The internal record IDs are used by MirrorSync when scanning for deletions, but I think it will be OK as long as they are in the same *relative* order. To ensure this, make sure that the records import into the new file in the same order that they existed in the original file.

Thanks Jesse. I assume the internal IDs are not the same as the Primary Keys in the database, right? (P.S. Is there any documentation that explains how all this process works? Would love to have a better understanding).

One thing mentioned in the article is that you have to "show all records" for each table. I am wondering if that is going to screw up the order of the internal record IDs and cause issues. Do you have users using another update process? I am definitely open to suggestions.

Right, internal IDs are not the same thing as primary keys. PK's will be unchanged during the import, but internal IDs will (in all likelihood) be different.

Show all records sounds correct. I'd recommend following up with an unsort command to make sure records appear in their natural creation order. 90% of the time this is not necessary, but if you happen to be on a layout that has the records set to sort by a certain order, then it becomes necessary.

Great, thanks Jesse. I'll do some testing and hopefully it all works seamlessly. Thanks!