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. Records created on separate devices will never have the same IDs.
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 introduced 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. Even sync systems that claim not to need UUIDs use them under the hood.
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, your 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 as their ID.
UUIDs in Worx: the UUIDDecimal Function
In the Worx example files that come with GoZync 5 you'll see that we're using a custom function for UUIDs instead of the native Get ( UUID ).
This function transforms the text based UUID to a number and since number indexes are smaller than text indexes, this can be a performance boost. If you have FileMaker Advanced, feel free to copy this custom function from our example files and use it in place of the native UUID function: just be sure to set the fields up exactly as we have in Worx, including making the ID a number field.