none
SSDT timeout when deploying a database

Answers

  • Hey Taddeusz,

    Sorry you are hitting this issue and that it has a severe impact on your customers. Although I can't speak to exact release dates, I can confirm that the ability to set command timeout through the registry will be available in the near future in an upcoming release of DACFx and SSDT. We also have work items on the books to expose this capability through SqlPackage.exe and the DACFx API in a later release of DACFx.

    Thanks again, and if you have any other questions or comments on SSDT or DACFx, please don't hesitate to let us know!

    Adam


    Adam Mahood - Program Manager - Data-Tier Application Framework (DACFX)/SQL Server Data Tools

    Thursday, August 30, 2012 12:02 AM
  • Hi,

    We also hit this problem in our project and we did the following 'workaround'.

    Basically we 'mimic' the deploy operation by calling the DacServices api from within powershell, you can find it's documentation on MSDN (look for "Microsoft.SqlServer.Dac.DacServices" - I can't post links yet).

    Our workaround for deploying a dacpac consists of:

    • DacServices.Extract current schema into a 'temp' dacpac
    • DacServices.GenerateDeployScript with the 'temp' dacpac and the one you actually want to deploy, the result is a script that actually performs the schema change.
    • Run this script through sqlcmd with a (long) timeout setting

    Hope this helps (until an 'official' solution is provided).

    Best regards,

    Jeroen Janssen

    • Marked as answer by Tadeusz Thursday, October 17, 2013 9:39 PM
    Thursday, October 17, 2013 9:14 PM

All replies

  • Hey Taddeusz,

    Sorry you are hitting this issue and that it has a severe impact on your customers. Although I can't speak to exact release dates, I can confirm that the ability to set command timeout through the registry will be available in the near future in an upcoming release of DACFx and SSDT. We also have work items on the books to expose this capability through SqlPackage.exe and the DACFx API in a later release of DACFx.

    Thanks again, and if you have any other questions or comments on SSDT or DACFx, please don't hesitate to let us know!

    Adam


    Adam Mahood - Program Manager - Data-Tier Application Framework (DACFX)/SQL Server Data Tools

    Thursday, August 30, 2012 12:02 AM
  • My client is running into this issue with a couple of internal development teams being unable to deploy their database projects anymore.  What is the current status of getting this issue addressed in some fashion?

    Given that SQL Server Data Tools has shipped a September and a November release since this forum question was first submitted, does "near future" or "upcoming release" mean either one of these two releases?  Even just having the tools respect the registry timeout setting would be immediately helpful and a welcome short-term fix.

    Thank you!

    Brad

    Tuesday, December 11, 2012 7:44 PM
  • Hi,

    I have a very similar problem. So, do you have any news about setting the timeout?

    Thank you!

    Wednesday, August 28, 2013 3:26 PM
  • I experience the same problem trying to automate deployment via continuous integration. Post-deployment scripts may run longer than the default COMMAND timeout which is not currently configurable. Can someone post a follow-up on Brad's question? Since the so-called "accepted answer", August 2012, numerous update releases have been published for SSDT by Microsoft. It is now Oct 2013, and no word yet? Bravo! Bravo!
    Wednesday, October 02, 2013 8:54 PM
  • Hi Adam, 

    Our customers are still experiencing the issue with the current SSDT and DACFx release. I do hope that by "near future" in the reply over a year ago you didn't mean "a few years" as in terms of software release, that's definitely not near future.

    Tadeusz


    Tadeusz Dracz


    • Edited by Tadeusz Thursday, October 17, 2013 9:35 PM
    Monday, October 07, 2013 6:22 PM
  • Hi,

    We also hit this problem in our project and we did the following 'workaround'.

    Basically we 'mimic' the deploy operation by calling the DacServices api from within powershell, you can find it's documentation on MSDN (look for "Microsoft.SqlServer.Dac.DacServices" - I can't post links yet).

    Our workaround for deploying a dacpac consists of:

    • DacServices.Extract current schema into a 'temp' dacpac
    • DacServices.GenerateDeployScript with the 'temp' dacpac and the one you actually want to deploy, the result is a script that actually performs the schema change.
    • Run this script through sqlcmd with a (long) timeout setting

    Hope this helps (until an 'official' solution is provided).

    Best regards,

    Jeroen Janssen

    • Marked as answer by Tadeusz Thursday, October 17, 2013 9:39 PM
    Thursday, October 17, 2013 9:14 PM
  • Thank you Jeroen - I will try doing that. 

    Best regards,

    Tadeusz


    Tadeusz Dracz

    Thursday, October 17, 2013 9:41 PM
  • The key is available, we probably didn't reply to this thread.  Depending on your product use this registry key to alter the query timeout.

    HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\SQLDB\Database\QueryTimeoutSeconds

    or

    HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\SQLDB\Database\QueryTimeoutSeconds

    Friday, October 18, 2013 4:26 PM
  • We already set the key to 0 and our customers still get timeout from time to time. It happens when data is copied to a temporary table due to required modifications and the related table has millions of rows, so it takes a while.

    Also, I made a little experiment. I set both registry keys to 30 and added 

    WAITFOR DELAY '00:05:00' to the pre-deployment script (this is 5 minutes wait).

    The deployment didn't timeout although in my view it should after 30 seconds.


    Tadeusz Dracz

    Friday, October 18, 2013 11:50 PM
  • I had this solution working at some point but after an upgrade it stopped working. It turns out that "Software\Microsoft\VisualStudio\10.0" is hardcoded as registrykey in Microsoft.Data.Tool.Schema.Common.RegistryManager.EnsureInitialized() even though I'm running latest version of DAC.

    Redmond owes me cake for that error! :)

    Tuesday, January 14, 2014 10:53 AM