GoZync5

UUIDs

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:

BEE43FEB-E230-449B-B8F4-D3871EF3012F

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...

1. Turn it into a text field (you may have had it as a number originally).

2. Add an auto-enter calc. Click "Options" and then "Specify" next to "Calculated value". Enter the following as the calc definition:

Get ( UUID )

Your calc should look like this:

3. Set it to not be modifiable. Click "OK" on the screen above and make sure your auto-enter options are set like this:

4. Make sure these ID fields are not on your sync layouts. GoZync will pick them up: you don't want these represented on your sync layouts. Those layouts are just for data.

5. Make sure these ID fields are indexed. If not, you will get a "Relationship Invalid" error when you run the "Test GTRR" script.

6. Finally, if your tables didn't have ID fields and you're creating these UUIDs as new fields, you'll need to give all your existing records values for these IDs before you can sync. Turn the "prohibit..." option off in the field's definition and run Records / Replace Field Contents to see values in here. Then turn "prohibit..." back on.

That's it.

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.

Since some of your older records likely have non UUID ids in these text fields, performing finds on these fields will be different: performing a find for the ID "23" will find record 23 but also record "235". This doesn't affect GoToRelatedRecord, just finds, so change any finds you have searching IDs to use "==23" instead of just "23".

And you'll also want to change all your foreign keys to text as well (if they were set as numbers). This is just a matter of changing their field type; you don't need to mess with the data. (If you want to stick with numbers, check out he UUIDDecimal function below.)

That's important: you're changing to UUIDs "going forward"; you don't need to go back through your old records and give them UUIDs (that would break your relationships). You didn't need UUIDs when your records were created on a networked system, you only need them now that (some of) your records will be created on a distributed system (where not all users are online when creating records).

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.