Can MirrorSync retrospectively merge

[MikeKD]

Hi there,

I've just become aware of MirrorSync this morning :-)

 

I'm under time pressure to let another teacher use the dept assessment database I've written.

I was going to let them populate it with their own data and merge it at the end of the year.

 

It will probably take a reasonable amount of time for out IT team to instal Filemaker / MirrorSync on the school server. Will it then cope with retrospectively merging a couple of weeks of data, or should I hold out deploying until it's ready if at all possible?

 

Also, does MirrorSync handle update to the database itself; improved scripts etc?

 

Cheers!

Mike

[Jesse Barnum]

Hi Mike - the answer is unfortunately no, you need to configure MirrorSync in advance before entering new data that will be synced.

 

It sounds to me like your initial data entry case might be easy to handle manually - switch your primary keys to UUIDs (by using a text field with a Get(UUID) auto-enter calculation), both use separate copies of the database, and then when you're ready to merge them, simply import all the records from one database to the other. The UUID key fields will ensure that there are no conflicting primary keys.

 

Once you have merged the data, then it would probably be a good idea to set up MirrorSync to keep the files in sync with each other from that point forward.

 

Regarding your question about database updates, let me point you to this section of the documentation:

 

http://docs.360works.com/index.php/MirrorSync_basic_setup#Distributing_new_versions_of_your_application

[MikeKD]

Many thanks Jesse,

Are UUID primary keys what I'll need anyway for MirrorSync?

One minor problem is that I've no idea what a UUID is I'm afraid!

 

I'll have another look at the procedure for updates later!...

[Jesse Barnum]

A UUID (Universally Unique Identifier) is a long (36 character) pseudo-random string of letters and numbers, that is sufficiently random that you can generate one knowing that it's extremely unlikely that another UUID will be generated anywhere else with the same 36 characters.

 

UUIDs make it much simpler to merge databases together, because you don't have to worry about have the same UUID created in two different databases like you would if you were using serial numbers. For this reason, many sync solutions require you to use UUIDs.

 

MirrorSync can work with either traditional serial number primary key fields or UUIDs. Since you will need to do your own merge without MirrorSync, it will be much simpler if you use UUIDs, and that will be compatible with MirrorSync when you switch to that.

[MikeKD]

Wouldn't it be easier to just add the users initials to the UID? I think I can see the advantage to a UUID (but isn't there a chance one could be duplicated?!) but I can't quite see how to generate them!!

 

When I do updates, do they have to be done from the server, or can I do the work on FM on my laptop, save it to the server and then do it?

 

Really sorry for my stupid newb questions!!

 

Cheers,

Mike

[Jesse Barnum]

The user initials would work fine, although that's actually more work for you, because you need to customize each file separately with the users initials and incorporate that into the primary key.

 

Generating UUIDs in FileMaker 12 or later is really easy: Just create a text field with an auto-enter calc of Get(UUID). Be sure to uncheck the box that says Do not replace existing value of field".

 

The chance of a duplicate UUID is not worth worrying about:

http://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates

 

If you want to work on your laptop and then replace the file on the server, that's fine with MirrorSync, but follow these instructions to reset the sync data after doing it:

http://docs.360works.com/index.php/MirrorSync_advanced_topics#When_in_doubt.2C_do_this.E2.80.A6

[MikeKD]

Many thanks, starting to replace IDs with UUIDs now...