I can see the issue. For instance, an invoice ID related to inventory, where the invoice ID is the PK number. Two salesmen on their iPads take an order where their local database assigns the same PK number. When merged you have two invoices with the same ID. Seems a classic problem with non centralized input. A second field, such as salesman ID, would need to squashed into that invoices PK number to guarantee a uniqueness to the number, assuming every salesman has a unique ID.
------------ Scott Doctor scott at scottdoctor.com On 5/20/2015 3:08 PM, Steven M. McNeese wrote: > 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. >
