Covering SQL Azure Data Sync and Microsoft Sync Framework
SQL Azure Team Blog
Sync Framework Developer Center
JuneT - Idle Thoughts
Liam's Cloud Data Service Blog
I am extremely happy to announce the public preview of our new Data Sync Service for SQL Azure. For those of you who have been following this blog, you might recall our Project “Huron”. In this project we talked about our vision of creating a Data Hub in the cloud to provide users with the ability to seamlessly share and collaborate on data regardless of the location and regardless of network connectivity. Back in November ’09 we introduced SQL Azure Data Sync as the first part of this vision which was to take SQL Server data and extend that to the cloud and then take that data and share it with other SQL Server databases.
Now with the Data Sync Service we are extending on the "Huron" vision. With no code, you can configure your SQL Azure database to be synchronized with one or more SQL Azure databases in any of our Windows Azure data centers. By doing so, it provides you the ability to extend that data to the location closest to your end users. All the while our scheduled synchronization service moves changes back and forth between these databases ensuring that changes get propagated to each of the databases in the data center. In conjunction with SQL Azure Data Sync, this data can also be synchronized back on-premises.
I have a TechEd session this week where I will be demonstrating all of this as well as how we will be extending the capabilities of the sync framework for creating offline applications, specifically allowing Silverlight, Windows Phone 7 and even non-MSFT platforms to be used for the clients.
If you are interested in giving the Data Sync Service a try please go to http://sqlazurelabs.com and click on “SQL Azure Data Sync Service” and send us your registration code. Starting early next week we will start adding registered users to the service.
I am really looking forward to your feedback.
This may have it's place, but I'd just really like the ability to back up my SQL Azure database on a scheduled basis, and without putting all of the Data Sync Service change tracking junk in my db.
I'm a production customer on SQL Azure, but what I read from most blogs/posts is that others won't move to production on SQL Azure because of the limited abilities for backup/restore.
p.s. Would have really loved a warning on datasync.sqlazurelabs.com that you were going to change my database schema before it happened... and have a way to remove it.
First of all thanks for the feedback and my apologies for issues the added metadata may have caused to your system. Your comments have not been uncommon and a number of people have also asked for a less intrusive way of exchanging data. One example of a similar request is for a way to aggregate data efficiently into a SQL Azure database. It is scenarios like this that could be built in such a way that it would not need to make changes to your existing database and is something we are investigating in more detail.
As for you point about a warning, I agree that this is a really good idea and so we have now implemented this as a highlighted point in the introduction email we send when a user is approved. I will also add this as a note for a future service upgrade to warn the user of object creation before the Sync Group is actually created.
Finally for de-provisioning of these object, this is a feature we are planning on adding to our Sync Framework 2.1 release and should be something we will be able to easily add to the service as well. I have made note of this in the work item databases.
Once again, thanks for the feedback.
I have gone through your articles about data sync. Its cool and really useful, but still i stuck with few issues. The issues i face in using the data sync are
1. In future if i want to add one more table to the data sync will i be able to add it?
2. Can i do a data sync to existing database in sql azure? with 2.0 frame work it says the db already exist and i was not able to set up it so i was forced to go for new db.
In production enivronment if something goes wrong its not advisable to create a new db, i would appreciate if you can advise me on this.