Creating order IDs on several handhelds

  • Thread starter Thread starter jonathan.dudley
  • Start date Start date
J

jonathan.dudley

Dear all,

I have a PC and handheld application that among other things, create
customer orders. It is possible to create customer orders on either the
PC or the handheld. There may be many handhelds fulfilling orders. The
orders from the PC can be transferred onto the handheld to be carried
out and orders, having been fulfilled on a handheld, are synchronised
back to the PC (using csv files, not merge replication etc).

Each order has an ID that must be unique, as I need to be able to match
orders on the PC and a handheld and check their last modified date-time
in order to decide which version should be kept during a synchronise
operation.

So I was wondering, if I am creating orders on the PC and on multiple
handhelds, how can I be sure that the same ID is not used on more than
one device, creating a conflict at a later stage during a
synchronisation? Should I have an extra field in the database,
CreatedBy, for example, which contains the ID of the device on which
the order was created, and have the primary key as a combination of
this field and the order id?

What is the best way to solve this problem?

Thanking you all,

Best regards,

Jonathan
 
Use a PK check-out model. You have a range of order IDs, when a device
connects with a server it "gets" a range from the server. The server marks
these as unusable until a check-in from the device that checked them out.

Another option is to assign a GUID to each order.

-Chris
 
I would definately use a GUID for identification, and the ordernumber (int)
generated by the server only for use as a customer reference.
 
Jonathan,

I'm using a GUID for this in my apps that use CSV files. Once you get the
CSV files on the desktop, your desktop app can decide what to do with the
GUIDs at that point, or if you want to use another additional primary key.
 
I wanted to keep my server ids linear, so I generate a unique guid like id
from the handheld for each new record, then send the record to the server,
and the server sends back it's primary key id which I then update the local
record with. Its not fully transactional (it could fail on sending back the
server pk id), so I store the guid on the server in a log and check all new
entries against the log in case the handheld tries to resend the same record
twice.

-Dave
 
Back
Top