I am unable to use the SQL Data Sync to sync a database we have at an on-premises server with our Azure database. When I attempt to refresh the schema so I can configure the sync rules, it stays in "processing" and never goes past that. This occurs when selecting the option to refresh the schema for the Azure database as well as the on-premises database. Everything is solid as far as the sync client setup on the on-premises server. It shows as "Online" in the management portal as well.  I just can't refresh either schema so that I can define sync rules.

There is not other info provided, in either the logs or through notifications.  Just "Processing".

Last tried:  8/23/2015 7:00 PM CST

Azure SQL Database Subscription ID: 3d9dcfea-332d-487b-9e7b-6053b722c163

Sync Agent: SiteProMasterSync

Sync Group: AmplisineMasterSyncGroup

how many tables do you have on the database?

as a workaround, try scripting the tables you want to sync, create a new db and create empty tables based on the scripts you generated earlier. you can then the add the new db to Data Sync and refresh the schema from that DB. 

That doesn't really solve my problem though.  If I can't even get it to refresh the schema on an existing Azure database, then I wouldn't think it would be useful to create an empty replica, unless there's something I'm not seeing.

My problem is that I have over 120 locations feeding into my on-premises database, so I want to create the data sync so that I can make a smooth transition over to using purely the Azure database, rather than stopping all data feeds into my in-office server and then redirecting all of the incoming connections to the Azure database.  This also provides a great way to fully test my azure site before launching it.

The Refresh schema is only there so you can pick the tables you want to sync, it has nothing to do with the synchronisation.

once, you picked the tables you want to sync, then provisioning can proceed.

By forcing the Refresh Schema to go against empty tables, you're isolating a known issue with Refresh Schema dealing with certain table counts/db size.

• Edited by JuneTMVP, Editor 19 hours 6 minutes ago

The Refresh schema is only there so you can pick the tables you want to sync, it has nothing to do with the synchronisation.

once, you picked the tables you want to sync, then provisioning can proceed.

By forcing the Refresh Schema to go against empty tables, you're isolating a known issue with Refresh Schema dealing with certain table counts/db size.

• Edited by JuneTMVP, Editor 18 hours 56 minutes ago

Sadly enough, as much as I wanted that to work, it did not.  It still stays stuck on "Processing".

• Edited by SirAaronPhillips 16 hours 19 minutes ago

Sadly enough, as much as I wanted that to work, it did not.  It still stays stuck on "Processing".

• Edited by SirAaronPhillips 16 hours 9 minutes ago

The Refresh schema is only there so you can pick the tables you want to sync, it has nothing to do with the synchronisation.

once, you picked the tables you want to sync, then provisioning can proceed.

By forcing the Refresh Schema to go against empty tables, you're isolating a known issue with Refresh Schema dealing with certain table counts/db size.

• Edited by JuneTMVP, Editor Monday, August 24, 2015 12:11 PM

The Refresh schema is only there so you can pick the tables you want to sync, it has nothing to do with the synchronisation.

once, you picked the tables you want to sync, then provisioning can proceed.

By forcing the Refresh Schema to go against empty tables, you're isolating a known issue with Refresh Schema dealing with certain table counts/db size.

• Edited by JuneTMVP, Editor Monday, August 24, 2015 12:11 PM

The Refresh schema is only there so you can pick the tables you want to sync, it has nothing to do with the synchronisation.

once, you picked the tables you want to sync, then provisioning can proceed.

By forcing the Refresh Schema to go against empty tables, you're isolating a known issue with Refresh Schema dealing with certain table counts/db size.

• Edited by JuneTMVP, Editor Monday, August 24, 2015 12:11 PM

The Refresh schema is only there so you can pick the tables you want to sync, it has nothing to do with the synchronisation.

once, you picked the tables you want to sync, then provisioning can proceed.

By forcing the Refresh Schema to go against empty tables, you're isolating a known issue with Refresh Schema dealing with certain table counts/db size.

• Edited by JuneTMVP, Editor Monday, August 24, 2015 12:11 PM

The Refresh schema is only there so you can pick the tables you want to sync, it has nothing to do with the synchronisation.

once, you picked the tables you want to sync, then provisioning can proceed.

By forcing the Refresh Schema to go against empty tables, you're isolating a known issue with Refresh Schema dealing with certain table counts/db size.

• Edited by JuneTMVP, Editor Monday, August 24, 2015 12:11 PM

Sadly enough, as much as I wanted that to work, it did not.  It still stays stuck on "Processing".

• Edited by SirAaronPhillips Monday, August 24, 2015 2:58 PM

Sadly enough, as much as I wanted that to work, it did not.  It still stays stuck on "Processing".

• Edited by SirAaronPhillips Monday, August 24, 2015 2:58 PM

Sadly enough, as much as I wanted that to work, it did not.  It still stays stuck on "Processing".

• Edited by SirAaronPhillips Monday, August 24, 2015 2:58 PM

Sadly enough, as much as I wanted that to work, it did not.  It still stays stuck on "Processing".

• Edited by SirAaronPhillips Monday, August 24, 2015 2:58 PM

Sadly enough, as much as I wanted that to work, it did not.  It still stays stuck on "Processing".

• Edited by SirAaronPhillips Monday, August 24, 2015 2:58 PM

Hi,

I'm afraid that the schema refresh issue is caused by one limitation of SQL Data Sync Service, which is currently we only support 500 tables as max in one sync group. From our service backend, the error message shows that: Unable to process a schema with 513 tables, 500 is the max.

So in order to resolve this issue, could you please consider to remove some unnecessary tables on your on-premises database if possible?

Also, the user experience of this should be improved since stuck on "Processing" without any error message won't help you to understand the situation. We are working on that, thanks for your reporting.

Regards,
Bowen

Bowen,

Thank you for the help!  Alright, I have removed some tables.  I currently have 491 tables.  The schema refreshes as it needs to.  However, a new problem has occurred:  After selecting all of the tables for syncing, and hitting saved, it tells me that the sync group failed to be provisioned.  When I click "Details", it just says the same thing twice (Sync group failed to be provisioned).  

Could you look on your side and let me know what's wrong now?

---Edit---

I was able to save a single table.  So there must be a certain table that is not playing nice.  I'll continue adding each table 1 by 1, but in the mean time, could you verify the problem on your end?

• Edited by SirAaronPhillips 5 hours 33 minutes ago

Bowen,

Thank you for the help!  Alright, I have removed some tables.  I currently have 491 tables.  The schema refreshes as it needs to.  However, a new problem has occurred:  After selecting all of the tables for syncing, and hitting saved, it tells me that the sync group failed to be provisioned.  When I click "Details", it just says the same thing twice (Sync group failed to be provisioned).  

Could you look on your side and let me know what's wrong now?

---Edit---

I was able to save a single table.  So there must be a certain table that is not playing nice.  I'll continue adding each table 1 by 1, but in the mean time, could you verify the problem on your end?

• Edited by SirAaronPhillips 5 hours 24 minutes ago

Glad to know you can refresh the schema successfully. :)

Refer to the problem "sync group failed to be provisioned", may I know how many times did you try to select all tables and save? As from our service backend, I didn't find any related failed requests. So the error you were facing might be related to an Azure Portal issue which doesn't related to sync service. If you only did that once, I would recommend you to try again, as save table 1 by 1 will be quite tedious.

Regards,
Bowen

I am getting that error at random, whether it be on a single table or all tables.  Every now and again, it still get stuck on "Processing...", just like it did when I couldn't refresh my schema.  Maybe that means there are error logs available on your back-end now?  That seems to be the unifying theme for when it gets stuck in "Processing...".  When it gets stuck, we get answers!

I was marking computed columns!  Idiot.  I'll uncheck those from the sync rules and let you know what happens.

• Edited by SirAaronPhillips 4 hours 32 minutes ago

I was marking computed columns!  Idiot.  I'll uncheck those from the sync rules and let you know what happens.

• Edited by SirAaronPhillips 4 hours 23 minutes ago

Alright, I tried, while not including the computed columns, and it still errors out.

Bowen,

Thank you for the help!  Alright, I have removed some tables.  I currently have 491 tables.  The schema refreshes as it needs to.  However, a new problem has occurred:  After selecting all of the tables for syncing, and hitting saved, it tells me that the sync group failed to be provisioned.  When I click "Details", it just says the same thing twice (Sync group failed to be provisioned).  

Could you look on your side and let me know what's wrong now?

---Edit---

I was able to save a single table.  So there must be a certain table that is not playing nice.  I'll continue adding each table 1 by 1, but in the mean time, could you verify the problem on your end?

• Edited by SirAaronPhillips Tuesday, September 08, 2015 1:41 AM

I was marking computed columns!  Idiot.  I'll uncheck those from the sync rules and let you know what happens.

• Edited by SirAaronPhillips Tuesday, September 08, 2015 2:41 AM