>Which end are you referring to with 'locally' ?

Locally is the client site.

>The in-store system must have a database and, presumably, so does your web server. What additional data storage would you need?

I do not need additional data storage if I use the approach I think I would have to use. If I would have to go with an approach to keep some references locally, in order to ease the synchronization, then, in this case, there would have to be a need to have an additional storage locally.

>I was assuming you had an SQL DB on the web server. Regardless of how you store the data there my suggestion still makes more sense to me - except you would have to use a web service on the web server rather than accessing the DB directly.
>Earlier you said that the clients machines will not have web server capability so that rules out a web service at that end anyway.

Yes, my server is SQL Server. Also, the approach to collect the data at run time from the local client site, by the use of a Web Service, but in reverse side, is something that will never happen. I do not want to rely on the client site for a guaranteed up time. I need to guarantee an up time service from my infrastructure only. If the client site goes down, connection failure, ISP not working, etc., then this could create a situation that some parts of the Web server would work but not the store options. Also, as I said, those clients do not have one single dollar to install a line, an adequate line, to host a Web Server locally, or to even pay to something else.

>In essence you are going to have to write software to monitor for changes on the client database and you are going to have to install some software on the clients machine so why not do the monitoring there? When it detects or decides to push changes have it call a web service on your web server which will be responsible for updating the DB at that end.

Ok, I see what you mean. Thanks