UUIDs are especially useful if your needs include importing or syncing data. Otherwise, IMHO a serial number works perfectly well. If you do use UUIDs, why do you want to convert them to numbers? I'd stick with FileMaker's built-in Get(UUID) function, which returns text, and avoid the extra complexity. Lastly AFAIK there's no problem implementing a sequence generator within a single file. FileMaker has effectively no limit on number of tables.
If placed in a separate file the sequence generator is not affected by any updates of your solution file. That is, after all why some solutions are made up of more than one file. It allows you to update one file while leaving others alone.
I am concerned that converting a uuid to a number might not produce unique values, but there may be implementation details to that which make it work.
But test any drop down lists or pop up menus that enter an ID with your new UUIDs. Your mileage may vary but problems with the width of the displayed value list are one of the reasons why I still use serial numbers in many cases.
Can't say that resetting serial numbers as part of the script that imports data from old into new was all that hard for me to set up as long as the serial is in a number field, not text.
You can get by with serial numbers if you have a single data source. Nowadays we utilise shared data from multiple sources. In these situations, a UUID is essential.
Not really, we were synching data from multiple sources long before we had UUIDs, but I fully agree that they are the better option when such is the case. We have a solution where over 300 ipads push data up to one of our servers. It would be MUCH more difficult to do without UUID's.
But I also recognize a few of the draw backs to UUIDs and thus do not exclusively use UUIDs in my work as sometimes it is not the best option.
And please note that you are not simply
"changing over to UUID values stored in number fields"
The methods described in that link CONVERT the UUID text into a numerical equivalent. That should, in theory, preserve the uniqueness of the value while permitting the data type change.
This is what I referred to when I mentioned "implementation details".