Rudy, I did something similar once, partly to see how hard it would be. I would not race into doing it again unless there was some really compelling reason.
Assuming there is that compelling reason the process worked something like this: a) go through every table affected and add the UUID field b) at the same time remove the old relations & draw in the new ones c) write a conversion method(s) to loop through all affected records i) lookup the linked records based on the old longint field ii) set the new UUID foreign key d) update all the queries that relied on the old key fields Personally I'd retain the old longint fields and keep incrementing them though in most cases I'd drop the indexes. The reason being it's useful to have a user-readable serial number that isn't an actual 'key field' but is unique enough to be useful doing ad hoc queries and debugging. It will also prevent any direct queries on it from failing though they will get slow (and identifiable) if you dropped the index. Queries that relied on the relations will fail and also be easy to spot. On Wed, Oct 24, 2018 at 7:52 AM Two Way Communications via 4D_Tech < [email protected]> wrote: > I have an application with a big database file ( + 60 GB), with 128 > tables. (4D v17) > > All id fields and foreign keys are of type longint. > > Now, for replication and sharing purposes, I would like to change the type > to UID. > -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
