According to FileMaker there is an issue between iOS 7 (due to be released on Sept 18) and FileMaker Go that affects the creation of a unique UUID number, which has the potential to wreak havoc on databases that rely on that unique number for syncing. This bug hits our own databases, as well as the copy of the database that is hosted at this blog.
Syncing from multiple copies of a database requires that each record have a very unique number. This is more than a straight serial number, since two separate copies of the database can each create a record in the same table which would give them the same serial number. Instead, our database relies on something more specific, a UUID which is generated from several types of information.
- recid (an internal number generated by FileMaker)
- the NIC (or MAC) address of the device that created the record
This is stored as a custom function to allow all tables in the database access to it.
According to FileMaker, all iOS devices under iOS 7 will return the same NIC address,. This can theoretically return the same UUID for two records if two devices created a new record in the same table at the exact same time.
I am not very worried about this myself. The odds of two records returning the same UUID are pretty small. Also the syncing scripts that I have use items other than the UUID for matching. For instance each new record is given _DeviceCreated and a _DeviceModified fields. Those are set to auto-enter a calculation [Get ( SystemPlatform ) & “-” & Get ( HostName )]. So unless both devices are iPads and are both named the same (which shouldn’t happen), they won’t supply the same data.
If you are worried about this bug you can switch from using the UUID.New function to another of Jereme Bante’s functions named UUID.Random which replaces the NIC portion of the UUID to a set of random numbers. Switching to this function won’t affect your old records and won’t require that you wait for FileMaker to fix FMGo.