We have a local server with an access database which feeds data to clients in the same domain. Now we also have a website which is hosted externally, and working on a bridge system to provided upload/downloaded functionality of products, categories and orders etc.

Products, categories and customers etc. can only be added locally, however, orders can be added both locally and on the website. We are trying to have these synchronised by the bridge application which uses Web Services. We have had this working but have come across more issues. Our current approach is:

• Every individual record has a local id (luid) and a web server id (suid), one example of usage is when an item is added on the website, it is given a unique suid and the luid is -1, once the item is downloaded by the bridge application, an luid is applied and updated. This is the inverse for items added on the local server.
• Every indivdual record also has a flag field (highlighting insert, update, remove(from the website) and delete).

The above works well - apart from the luid and suid approach has made it impossible to easily track record relationships once an item is downloaded. This approach only seems to work well for one-way data - i.e. just uploading products to the website for viewing (and updating and removing them dynamically).

To solve this problem I have considered using GUIDs or perhaps COMBs GUID approach which means that items can be added on both sides and synced appropriately, thought the performance hit concerns me slightly.

Some important points are:

• The local server is the data "base camp" where everything needs to be (eventually) stored.
• Only the local bridge application can make requests to the web server due to web services.
• Needs to support the chance the there may not always be an internet connection, so requesting unique IDs from the web server is not ideal.

Does anyone have an opinion on a much better programming approach to handling this sort of synchronisation ?