There are other options which may be more attractive if you are willing to put more work in your synchronization code. I did something like this years ago before UUIDs existed. You need to be able to identify shared records (which can be a UUID field without it being the primary key) and then update the foreign keys with the right integer values as they are transferred into the target database.
John DeSoi, Ph.D. > On Oct 24, 2018, at 11:31 AM, Two Way Communications via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > To be clearer on the purpose: > > There are many customers who use my application. > > What I want to achieve is that they can ’share’ data. In order to do that, I > really do need a UUID, because I intend to exchange the records (and related > records) between their individual databases. > Obviously this will never work with LONGINT ids and foreign keys … > > Another example is replication. My users, most of the time, are working > client-server. But often, they need a part of the datafile as a local > database on their laptop, so I need to replicate at least a part of > the data into a stand-alone database. Then, if they add records to the local > database, I want to replicate that new information back to the server > database. > > The only way this would be possible is to change all the LONGINT ids to UUID, > and also the foreign keys …. ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
