7 Replies Latest reply on Oct 9, 2015 1:23 PM by tays01s



      I needed to ensure that distributed copies of a solution could synch import/export records so I've converted from serial numbers to UUID in my primary/foreign keys, scripts, values lists and conditional formatting.


      I am beginning to grind through the problems caused by the change. First one is that although each new Parent record gets a UUID, the Child records are the same for a particular parent.


      I'm using the 'random UUID' from the Brian Dunning site as a custom function in an autocalc text field to create the UUID.



        • 1. Re: UUID

          Get(UUID) was introduced in FM12, you would only need a custom function if you are using an older version of FMP.


          I suggest copying the old Primary key to a new field before changing to new uuid, then run a script that loops through the parent records, set a variable  ($oldid)  to the oldid and another variable ($newid) to newid then search the child table for the $oldid and replace with the $newid.

          • 2. Re: UUID

            I went through this process a couple of years ago for the same reason. To me the most important thing is to leave the current serial number system in place and add the new UUID fields separately. This enables you to maintain the existing relationships and use these to populate the UUID foreign key fields correctly. Assigning UUIDs as primary keys can be done using Replace with the calc Get ( UUID ). However, to pass this new parent UUID across to foreign key field in a child record, you must do it via the pre-existing serial number relationship (you can use Replace to do this). Once that has been achieved, and you are sure you have the correct UUIDs in place, you can then repoint the relationship to use the new UUID fields instead the old serials. Then you need to check EVERYTHING over and over to make are nothing is broken. When you are completely satisfied via your testing that everything is as it should be, you can then, if you dare, delete the old serial number fields.

            • 3. Re: UUID

              Solution: I'd forgotten that my scripts duplicate the last related record and of course duplicated the UUID. I instead needed to put Set Field [UUID, get(UUID)].


              Foreign keys: No I hadn't populated them, but that was because I'd deleted all child records so that I was starting from scratch and, I'd hoped, created child foreign keys with each new record.

              • 4. Re: UUID

                In the field auto-entry options, uncheck the option that says 'Do not replace existing value of field (if any)'. That will make it auto-enter a new UUID when you duplicate the record.

                • 5. Re: UUID

                  Good point. Both this and my solution work, but your is probably better because it's easily visible what's happening.

                  • 6. Re: UUID

                    That checkbox may not be the best choice, since you're doing a lot of importing.


                    If, in your Import[] script steps, you have "perform auto-enter options" checked, you'll get a new UUID!

                    • 7. Re: UUID

                      So in that case, it would be safer to stick to my script that sets the field to get (UUID) for the text field.