There exists a local server by having an access database which feeds data to clients within the same domain. Now we have an internet site that is located externally, and focusing on a bridge system to provided upload/downloaded functionality of items, groups and orders etc.

Items, groups and clients etc. are only able to be added in in your area, however, orders could be added both in your area and online. We are attempting to have these synchronised through the bridge application which utilizes Web Services. We've had this working but know of more issues. Our current approach is:

  • Every person record includes a local id (luid) along with a web server id (suid), an example of usage happens when a product is added online, it's given a distinctive suid and also the luid is -1, when the item is downloaded through the bridge application, an luid is used and up-to-date. This is actually the inverse for products added around the local server.
  • Every indivdual record also offers a flag area (highlighting place, update, remove(in the website) and remove).

The above mentioned is effective - aside from the luid and suid approach has managed to get impossible to simply history associations once a product is downloaded. This method only appears to be effective for just one-way data - i.e. just uploading items towards the website for viewing (and upgrading and getting rid of them dynamically).

To resolve this issue I've considered using GUIDs or possibly Hair combs GUID approach meaning products could be added on sides and synced properly, thought the performance hit concerns me slightly.

Some important points are:

  • The neighborhood server may be the data "base camping" where everything must be (eventually) saved.
  • Just the local bridge application could make demands to the net server because of web services.
  • Needs to facilitate the possibility the there might not necessarily be a web connection, so asking for unique IDs on the internet server isn't ideal.

Does anybody come with an opinion on a far greater programming method of handling this kind of 'synchronisation'?



A distinctive id is definitely likely to simplify things. I do not see why you ought to stress about performance, the GUID could be built from something machine-specific or ids could be released in tranches to ensure that normalid construction is really a purely local activity.