>You didn't mention 'till now that you were looking for a generic solution on the web server end. Since you are going to have to install software on each client site I'd put the bulk of the synchonizing logic there since it will be different for each one. This would be responsible for identifying changes in their database and pushing them to the web server database - either directly or via a web service on the web server.

Yes, but in order to be able to do that, it implies that I would have some kind of storage mechanisms locally and this is what I am trying to avoid because I would have to install a database mechanisms, XML or something like that. I would just like to have a Web Service that will collect the keys from the server with the time stamps and act upon that locally to decide what is new, what has to be updated and what has to be removed. As I will have to collect all the keys, I would try to push the synchronization mechanism on an hourly basis. Also, this targets in average between 50 to 1500 items. So, the XML, on an hourly basis, to get the keys shouldn't be that big. The big process will be mostly on the updates. I will have to implement some kind of mechanism, used for the first time, to send the updates in batch, at interval, in order to avoid eating all the bandwidth or the CPU. But, as this initial process is only done once or on recover mode, it doesn't matter that much.

>But if customers are not able to order on-line then I don't see why the currency of the web site content is critical - if they pitch up at the store a couple of days later the price and/or availablity could have changed in the meantime anyway...

Yes, that is also a point I tried to discuss. But, they had some kind of concerns about that.