These are the notes for GoZync 3. Docs for the latest version of GoZync--GoZync 4--can be found here. GoZync 4 is a free upgrade and is highly recommended (hint: it's faster).
What are UUIDs
These are "Universally Unique IDs" meaning they are unique across all the instances of your file running on distributed (i.e. offline) iPhones, iPads, or laptops.
Unlike a regular ID which may look like "35767" or "P_4676" UUIDs are longer and look like this:
Regular IDs can't be used in distributed solutions: if user A created invoice 12345 – because that was the next serial number in that file – user B is going to create 12345 sooner or later as well. And when those records get back to the server, you won't be able to tell them apart.
UUIDs include an element of randomness to them and generally some fact about the device that created them, so they're never duplicated. Fortunately we don't have to calc all that up as FileMaker 12 has a built in UUID function: Get (UUID)
Do I really have to switch my IDs to UUIDs?
Yes. There is just no other way to reliably disambiguate records created in the same table on different mobile devices. Period.
You'll also never have to reset your serial numbers after doing imports. =)
Do I need to change my existing data? What about relationships that already use my old IDs?
You do NOT need to change the existing values of any ID fields, just change their definition so that *new* records get the UUIDs.
The reason you don't need to change existing values is that before the system was synced (before it was a distributed system and it just ran on the LAN), serial numbers were a fine source of authenticity and uniqueness. So your pre-sync data still has integrity. In a distributed (synced) system, serial numbers are not a sufficient source of uniqueness and need to be replaced by UUIDs. But only for new records. Your existing data is fine as-is.
Can I really count on these being unique?
Yes. FileMaker stands behind them. And in our testing we've been running looping scripts to bang on these and have created records more than 20 million times with no duplicates. More on this here.
How do I set them up in FMP?
Take your existing ID field and...
Consequences of switching to UUIDs
There are two consequences you may want to look at after switching to UUIDs; both are more about switching to text keys than they are about UUIDs per se.
What if I still need "normal looking IDs" like for an invoice number?
If you've ever purchased something at the Apple store you've seen this in action: their hand-held checkout sleds are an example of a distributed app that uses UUIDs to keep their sales transactions straight. When you get a receipt in-store, it has a long barcode on it that is your UUID. Later, Apple will assign this record a more human-read able unique ID, but that isn't assigned at the time of purchase.
So taking this into the FileMaker world, you mobile devices can--and should--assign "mobile reference numbers" (UUIDs) to your transactions. If you need to give your customers more normal looking reference numbers later, you can have the server create these as part of a server-side script, perhaps when the orders are invoiced or "closed".
The idea is that your distributed data entry (what happens on your mobile devices) must use UUIDs, so those are what *really* identifies records in your system. Those are what you use for primary keys. If you need a more human readable version, have a non-distributed user (like FileMaker Server, or a user on your network) create these, but know they're like a nickname for the record: something your customers can use to refer to the record--and something you can search on--but you'd no more use this as the *real* ID of the record than you'd use a contact's nickname.