GoZync4

UUIDs

GoZync4.UUIDs History

Hide minor edits - Show changes to output

March 28, 2014, at 08:14 PM by 50.132.84.245 -
Added lines 52-53:

-> 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.
July 15, 2013, at 07:22 PM by 67.190.87.90 -
Added lines 51-52:
-> 5. Make sure these ID fields are '''indexed'''. If not, you will get a "Relationship Invalid" error when you run the "Test GTRR" script.
June 30, 2013, at 08:26 PM by 50.132.84.245 -
Changed line 69 from:
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.
to:
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.
June 30, 2013, at 08:24 PM by 50.132.84.245 -
Changed lines 17-18 from:
Yes. There is just no other way to reliably disambiguate records created in the same table on different mobile devices. Period.
to:
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.
April 10, 2013, at 03:16 PM by 50.132.84.245 -
Added lines 21-26:
!! 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.

March 16, 2013, at 05:24 PM by 50.132.84.245 -
Changed lines 55-56 from:
!! What if I still need "normal looking IDs" like for an invoice number?\
to:
-> 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?
March 16, 2013, at 05:21 PM by 50.132.84.245 -
Deleted lines 46-49:
!! What if I still need "normal looking IDs" like for an invoice number?\

 > > Need to add some notes here, re script on host, reference number on mobile.

Changed lines 53-61 from:
-> And you'll also want to change all your [[glossary | 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.
to:
-> And you'll also want to change all your [[glossary | 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.

!! 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
.
March 16, 2013, at 05:14 PM by 50.132.84.245 -
Changed lines 43-44 from:
-> 4. Make sure these ID fields are '''not''' on your sync layouts. GoZync will pick them up: you don't want these (or foreign keys) represented on your sync layouts. Those are just for data.
to:
-> 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.
February 26, 2013, at 04:25 PM by 50.132.84.245 -
Changed lines 17-18 from:
Yes. There is just no other way to reliably disambiguate records created in the same table on different mobile devices, period.
to:
Yes. There is just no other way to reliably disambiguate records created in the same table on different mobile devices. Period.
Changed lines 11-12 from:
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.
to:
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.
December 16, 2012, at 11:15 PM by 50.132.84.245 -
Added lines 43-44:
-> 4. Make sure these ID fields are '''not''' on your sync layouts. GoZync will pick them up: you don't want these (or foreign keys) represented on your sync layouts. Those are just for data.
Changed lines 49-50 from:
 > > script on host, reference number on mobile.
to:
 > > Need to add some notes here, re script on host, reference number on mobile.
December 10, 2012, at 10:17 PM by cm - minor edits and clarifications
Changed lines 5-6 from:
These are "Universally Unique IDs" which means that they are unique across all the instances of your file running on distributed (i.e. offline) iPhones, iPads, or laptops.
to:
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.
July 23, 2012, at 04:14 PM by 50.132.84.245 -
Changed lines 53-54 from:
-> 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 "245". This doesn't effect GoToRelatedRecord, just finds, so change any finds you have searching IDs to use "==23" instead of just "23".
to:
-> 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 effect GoToRelatedRecord, just finds, so change any finds you have searching IDs to use "==23" instead of just "23".
July 07, 2012, at 09:04 PM by 50.132.84.245 -
Changed lines 23-24 from:
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 20million times with no duplicates. More on this %newwin% [[http://en.wikipedia.org/wiki/Uuid | here]].
to:
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 %newwin% [[http://en.wikipedia.org/wiki/Uuid | here]].
July 07, 2012, at 09:03 PM by 50.132.84.245 -
Changed lines 51-55 from:
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.
to:
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 "245". This doesn't effect 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 [[glossary | 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.
July 07, 2012, at 08:44 PM by 50.132.84.245 -
Deleted lines 24-27:
!! 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.

Added lines 48-51:

!! 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.
July 07, 2012, at 08:44 PM by 50.132.84.245 -
Changed lines 11-12 from:
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 IDs get back to the server, you won't be able to tell them apart.
to:
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.
Changed lines 17-18 from:
Yes. There is just no other way to disambiguate records created in the same table on different mobile devices.
to:
Yes. There is just no other way to reliably disambiguate records created in the same table on different mobile devices, period.
July 07, 2012, at 08:43 PM by 50.132.84.245 -
Changed lines 17-18 from:
sigh
to:
Yes. There is just no other way to disambiguate records created in the same table on different mobile devices.

You'll also never have to reset your serial numbers after doing imports. =)

!! 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 20million times with no duplicates. More on this %newwin% [[http://en.wikipedia.org/wiki/Uuid | here]].

Changed lines 27-28 from:
Change your foreign keys
to:
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.
July 07, 2012, at 08:31 PM by 50.132.84.245 -
Changed lines 5-6 from:
"Universally Unique..." etc.
to:
These are "Universally Unique IDs" which means that 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:

-> @@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 IDs 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)

Added lines 42-45:

!! What if I still need "normal looking IDs" like for an invoice number?\

 > > script on host, reference number on mobile.
June 24, 2012, at 04:16 PM by 50.132.84.245 -
Added lines 7-10:
!! Do I really have to switch my IDs to UUIDs?

sigh

June 24, 2012, at 03:23 PM by 50.132.84.245 -
Added lines 7-10:
!! Consequences of switching to UUIDs

Change your foreign keys

June 24, 2012, at 03:09 PM by 50.132.84.245 -
Added lines 5-6:
"Universally Unique..." etc.
June 24, 2012, at 03:09 PM by 50.132.84.245 -
Added line 23:
-> That's it.
June 24, 2012, at 03:08 PM by 50.132.84.245 -
Changed lines 17-22 from:
%width=500 newwin% [[http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png | http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png]]
to:
%width=500 newwin% [[http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png | http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png]]

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

%width=500 newwin% [[http://www.seedcode.com/rootimages/stikipad/gozync/UUID2.png | http://www.seedcode.com/rootimages/stikipad/gozync/UUID2.png]]

June 24, 2012, at 03:06 PM by 50.132.84.245 -
Changed line 17 from:
%width=300 newwin% [[http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png | http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png]]
to:
%width=500 newwin% [[http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png | http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png]]
June 24, 2012, at 03:06 PM by 50.132.84.245 -
Changed line 17 from:
%width=300% %newwin% [[http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png | http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png]]
to:
%width=300 newwin% [[http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png | http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png]]
June 24, 2012, at 03:06 PM by 50.132.84.245 -
Added lines 7-17:
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:

%width=300% %newwin% [[http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png | http://www.seedcode.com/rootimages/stikipad/gozync/UUID1.png]]
June 24, 2012, at 02:59 PM by 50.132.84.245 -
Changed lines 1-2 from:
%title UUIDs%
to:
(:title UUIDs:)
June 24, 2012, at 02:57 PM by 50.132.84.245 -
Changed lines 1-2 from:
(%title UUIDs%)
to:
%title UUIDs%
June 24, 2012, at 02:57 PM by 50.132.84.245 -
Added lines 1-2:
(%title UUIDs%)
June 24, 2012, at 02:54 PM by 50.132.84.245 -
Added lines 1-4:
!! What are UUIDs

!! How do I set them up in FMP?

(855) SEEDCODE
support@seedcode.com
Follow us: