Data Synchronization with Client/Server
Normally, client/server applications are developed with the client requesting operations on the server (e.g. AddCustomer, ModifyCustomer, DeleteCustomer, DoSomethingWithCustomer, etc). There's usually also a client side cache so lookup and other frequently used data are loaded into the client.
Moving towards developing smart clients, the cache is made robust so it handles synchronization of data with particular synchronization strategies, handling offline mode, etc.
With the introduction of SQL Express and assuming all future machines will be preinstalled with SQL Express, could we not write the client as though it's a 1-tier application reading/writing straight to the local SQL Express database and somehow configure SQL Express to do the synchronization? If the synchronization configuration is not possible, maybe write your own custom synchronization layer that ensures data is synchronized between client and server?
Looking forward to hearing the different views on this.
It's easy when you only read the database. The real problems start when users are writing into the same record and even the same fields.
I worked on some three-tier solutions where this problem already exists, but we could handle this by interacting with the user in case something is wrong.
The question is, do you want to go back to the user when some kind of sync issue exists?
This is one of the scenarios we target with SQL Server Service Broker. Reliable communications, asynchronous, queued service execution on the server, and client side queuing can make this attractive. If you think about an asynchronous connection to the server, when the client wants to interact with the server, is sends an asynchronous message to the server. The server pulls the message off the queue, processes it and sends a message back to the client. The client then pulls the messsage of the queue and processes it - probably transactionally updating the client database. If the client is connected to the server, this whole process takes a second or less. If it's not connected, it might take days or weeks depending on how long it's disconnected. The cool thing is that the interaction works the same whether your connected or not - it just takes longer if you're disconnceted.
The other advantage of using Service Broker is that the communication is bi-directional. The client can send to the server or the server can send to the client at any time. If you want to keep the client data in sync with the server, the server can send a message to the client when something changes. If the network is connected, the changes are sent immediately. If not, the changes are sent when the connection is restored. Again, you just build the system to use reliable, asynchronous messages and there's no difference between connected and disconnected operations.
Jonathan van de Veen wrote: