locked
PerformPostRestoreFixup table limit and Timeout RRS feed

  • Question

  • Hello, I have a problem with the PerformPostRestoreFixup command.

    First I get an error with "255 table limit", with Profiler I have seen that this command does a UNION ALL with every table, I hace 350 tables and I get that error.

    On other side, I have a table with 30 million rows and I sometimes I get, also with PerformPostRestoreFixup command, a "Transaction closed" error and other times I get "timeout" error.

    What can I do?
    Sunday, January 31, 2010 11:36 AM

Answers

  • Hi Jorge,

    Thanks for pointing out this two issues. We are aware of them and are working on the fixes. For your scenario, is it a prototype for your new product or just a tryout? Also, may I know why your scenario needs to sync more than 255 tables in one database?

    For the UNION ALL limitation, we don't have a workaround. For now, you have to sync less than or equal 255 tables in a database.

    For the SqlCommand default timeout value, no property is exposed for you to change. A possible workaround is to create new sync scope for same set of tables with the provisioning APIs after restoring a database. You need to do the same thing for other databases that need to sync with this restored database. After that, all databases should use the new sync scope to sync with each other. It means that you have to re-initialize all your sync endpoints. With existing tracking table,s the re-initialization will not take a long time, but your scope_info table has an old scope that cannot be used anymore.

    Thanks,
    Dong




    This posting is provided AS IS with no warranties, and confers no rights.
    Tuesday, February 2, 2010 6:17 PM

All replies

  • Hi Jorge,

    Thanks for pointing out this two issues. We are aware of them and are working on the fixes. For your scenario, is it a prototype for your new product or just a tryout? Also, may I know why your scenario needs to sync more than 255 tables in one database?

    For the UNION ALL limitation, we don't have a workaround. For now, you have to sync less than or equal 255 tables in a database.

    For the SqlCommand default timeout value, no property is exposed for you to change. A possible workaround is to create new sync scope for same set of tables with the provisioning APIs after restoring a database. You need to do the same thing for other databases that need to sync with this restored database. After that, all databases should use the new sync scope to sync with each other. It means that you have to re-initialize all your sync endpoints. With existing tracking table,s the re-initialization will not take a long time, but your scope_info table has an old scope that cannot be used anymore.

    Thanks,
    Dong




    This posting is provided AS IS with no warranties, and confers no rights.
    Tuesday, February 2, 2010 6:17 PM
  • wouldn't it simply be easier to rollback in time and redo all actions instead of comparing data to data ??

    simply look at the metadata... what happened 24 hours ago until now ?...

     

    the rollback amount could be a value inserted by the user... 

    Wednesday, December 8, 2010 8:42 AM