I'm just beginning my R&D on SQL Server Replication for a project and had some questions about what paths to pursue
We have multiple locations which we want to all work off the same set of data essentially, but the kicker is that many of the sites become disconnected for minutes or either days at a time due to their remote locations, so we cannot simply deploy a web application with one SQL backend because remote sites will be unable to work during service disruptions.
Ideally, what I'd like to be able to do is have multiple instances of the SQL server/web applications(one at each site..they all have their own internal network), but which replicates with the main site/all other sites whenever it can(i.e. the internet is available). So one site goes without internet for a few days, they have up to date data from the last replication and they can work off their own sql server/web application, and any updates they've made/or any updates from other sites they've missed during the disconnected period would be replicated when the opportunity arises(ie. the web connectivity comes back)
Is this scenario possible? and I am struggling to find the right strategy path for implementing something like this. Any guidance would be greatly appreciated.
Thanks,
Chris
Yes this is possible. What you want is Merge replication. That will allow updates on the subscribers and they will sync when they are online.
I would recommend making the client a click once .net application rather than a web app as the click once will also update when online however web app will work too on the local servers. You will just need a mechanism to update the pages.
Martin
No comments:
Post a Comment