When a DataSnap Client app connects to a DataSnap Server's Remote Data Module and uses a TDataSetProvider + TClientDataSet, it caches a db table (or view) local to the client app. The user can make changes to the data in the TClientDataSet locally and ApplyUpdates(0) to synchronize the changes with the server. This all makes sense.
Using a SQL Server 2008 db, the primary key can be either an identity or a GUID field. Assuming the user will be offline while they add new records to the local TClientDataSet, how does the local TDataSetProvider and TClientDataSet handle assignment of the primary key field when the user creates a new record? Since the locally created records may be part of a master/detail relationship, it seems logical that a new primary key would need to be created locally. How is that resolved when the user does an `ApplyUpdates(0)'?
When several users create records in offline mode, how are primary key collisions resolved when they each do an ApplyUpdates(0)?
Is an identity field better than a GUID field, or visa versa? Why?
TDataSetProviderandTClientDataSetcreate offline primary keys in cached datasets and how primary keys are handled by these components when users synchronize their local cache with the server via a call toApplyUpdates(0). There may be issues with the way the components handle the primary key when using anidentityorGUIDfield -- thus question about which is best. - James L.