Activity overview
Latest activity by Mike U
Hi - I just wanted to let you know that we are looking at this problem, but we're currently unable to reproduce it. We'll update you as soon as we have any more information. / comments
Hi - I just wanted to let you know that we are looking at this problem, but we're currently unable to reproduce it. We'll update you as soon as we have any more information.
I'm pleased to tell you that this problem should be fixed in SQL Dependency tracker 3.3.4 / comments
I'm pleased to tell you that this problem should be fixed in SQL Dependency tracker 3.3.4
I'm pleased to tell you that this problem should be fixed in SQL Dependency tracker 3.3.4 / comments
I'm pleased to tell you that this problem should be fixed in SQL Dependency tracker 3.3.4
The automatic sourcing actually only happens for the older ReadyRoll way of creating an Octopus package (where the .nupkg is created as part of the Visual Studio build - https://documentation.red-gate.com/sca3/automating-database-changes/automated-deployment-with-sql-change-automation-core/using-octopus-deploy-with-sql-change-automation-core). When you're using the newer SQL Change Automation step templates this doesn't happen automatically at the moment. / comments
The automatic sourcing actually only happens for the older ReadyRoll way of creating an Octopus package (where the .nupkg is created as part of the Visual Studio build - https://documentation.red-g...
Any Octopus variable will automatically be converted into a SqlCmd variable / comments
Any Octopus variable will automatically be converted into a SqlCmd variable
From that log I can see that you're using the package deployment script method, which contains every migration you've ever written, and has to check each against the migration log at deployment time to decide which ones to execute. You're not actually using the SQL Change Automation PowerShell cmdlets there. I would suggest using the SQL Change Automation PowerShell cmdlets (https://documentation.red-gate.com/sca3/automating-database-changes). You'd use the build/package cmdlets to create a single deployment package, and then use the release cmdlets for each target database to create and execute a targeted deployment script for each one that will only contain the undeployed migrations for that database. / comments
From that log I can see that you're using the package deployment script method, which contains every migration you've ever written, and has to check each against the migration log at deployment tim...
Can you share the PowerShell script you're using, and the log output? If you're not happy sharing it here on the forum, you could contact support instead (assuming you have an active support contract) / comments
Can you share the PowerShell script you're using, and the log output? If you're not happy sharing it here on the forum, you could contact support instead (assuming you have an active support contract)
I suspect that's unavoidable overhead of setting up a transaction - but to be honest, 5 to 10 seconds doesn't seem that bad. Is the problem that you're deploying lots of databases, rather than the length of time for a single database? If so, have you tried running the deployments in parallel? / comments
I suspect that's unavoidable overhead of setting up a transaction - but to be honest, 5 to 10 seconds doesn't seem that bad. Is the problem that you're deploying lots of databases, rather than the ...
Can you see from the logs which bit is taking a long time? You might need to turn up the log verbosity to figure that out (how you do that depends on exactly how you're running the PowerShell). It will also depend, of course, on what's in the scripts to be deployed. If one of them does a massive index rebuild, fox example, it's bound by the performance of SQL Server itself. / comments
Can you see from the logs which bit is taking a long time? You might need to turn up the log verbosity to figure that out (how you do that depends on exactly how you're running the PowerShell).It w...
Whether it's significantly quicker or not depends on the size of your project (in terms of number of migration scripts and programmable objects), and how often you deploy. The patch-based method only deploys updates, so if you keep your target database reasonably up-to-date and you have a large number of scripts it should be significantly quicker. / comments
Whether it's significantly quicker or not depends on the size of your project (in terms of number of migration scripts and programmable objects), and how often you deploy. The patch-based method on...