You misunderstood. If an application running on a tablet for 2 users add rows to a local database with an auto increment key, each would get a key based on their database an let's say for grins they both start with a new clean database. User 1 gets key 1 and user 2 gets key 1. Now they push their data to a server each with key 1 but different data. That doesn't work. Both records needs to be added to the server database - a collection of all the data collected on the client tablets.
Sent from my iPhone > On May 20, 2015, at 4:38 PM, Jean-Christophe Deschamps <jcd at antichoc.net> > wrote: > > At 23:24 20/05/2015, you wrote: > >> On Wed, May 20, 2015 at 2:20 PM, Steven M. McNeese >> <steven.mcneese at freedomparkdfw.com> wrote: >> > Often times people will use GUIDs as primary keys when different systems >> > need to generate >> > rows and then merge together. Like an application that works with offline >> > clients that push the >> > data to a server when the connect. However there are other ways of >> > accomplishing the same thing. >> >> For curiosity - Is there a site/blog post somewhere >> enumerating/listing these other ways ? > > I don't know, but let's say your rowids range from -9223372036854775807 to > 9223372036854775807, that's 18446744073709551614 possible rowids. > > Imagine that in 50 years, the total population on Earth will grow to (say) 50 > billion people (I hope it won't!). > > 18 446 744 073 709 551 614 / 50 000 000 000 = 368 934 881.474 191 032 28 > > That leaves you the possibility to assign a unique identifier to every > potential client on the planet (and a big one) in nearly 369 million servers > concurrently without the faintest risk of collision. > > At this rate, you may limit rowids to only positive integers ... and hire a > large army of telemarketers. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
