Thanks for input.

It takes more storage space to do this, but it can save your bacon when two employees update the same record and you need to roll back to an older version.

For the most part, synchronization is more a theoretical problem, since most of the data entry for the nodes are the responsibility of a single person. I should probably mention, that the server software is also touching the data on a nightly basis, so the issue is not just two users stepping on each others toes, but also the system modifying the entries as well.

I don't think folding the entries on top of each other will be too bad. The app is designed to keep track of history, so that all entries are non-destructive. The only thing the synchronization really has to decide is what fields to merge within the records and which one comes out on as the latest entry when the same fields are changed.

Client side VBScript/Javascript using ADO should work fine on an Access database or some file that is stored on the user's hard drive.

Although I could try to push an MS only solution, I've been trying to avoid that scenario. Problem is that I don't really want to deal with the end users in any significant fashion. These users are not internal as the customers are from a number of different companies. My experience has been that once you start installing MS apps, you then have to take on significant customer support. The whole reason for writing a thin client in the first place was to keep my exposure to client problems to a minimum.

But since I am free of that Microsoft Shop, I'd most likely use Java and JDBC or something.

The main problem I have with Java is that I don't particularly like AWT or Swing. For importing and exporting the data, it would be a nice environment. But the problem I'm having is that I'm not sure how to build the user interface for the forms that I'm using in the web app.