Comments
Sort by recent activity
Are you just running the Deploy.ps1 included in the build output (which uses the Package deployment scripts method described here, and gets larger the more migration scripts you have), or are you using the SQL Change Automation PowerShell cmdlets (which use the Patch deployment scripts based method, and only need to run undeployed migrations)? / comments
Are you just running the Deploy.ps1 included in the build output (which uses the Package deployment scripts method described here, and gets larger the more migration scripts you have), or are you u...
Yes, restarting SSMS is a workaround for this. But you'll be glad to know that we've just released SQL Source Control 7.0.6 to Frequent Updates which contains a fix for this problem. You'll need to enable frequent updates to see this update. / comments
Yes, restarting SSMS is a workaround for this. But you'll be glad to know that we've just released SQL Source Control 7.0.6 to Frequent Updates which contains a fix for this problem. You'll need to...
These columns are documented in the MSDescription extended properties for the columns.
package_version: If you have enabled SQLCMD Packaging in your SQL Change Automation project, or if you are using Octopus Deploy, this will be the version number that your database package was stamped with at build-time. release_version: If you are using Octopus Deploy, you can use the value in this column to look-up which release was responsible for deploying this migration. If deploying via PowerShell, set the $ReleaseVersion variable to populate this column. If deploying via Visual Studio, this column will always be NULL. version: The semantic version that this migration was created under. In SQL Change Automation projects, a folder can be given a version number, e.g. 1.0.0, and one or more migration scripts can be stored within that folder to provide logical grouping of related database changes. / comments
These columns are documented in the MSDescription extended properties for the columns.
package_version: If you have enabled SQLCMD Packaging in your SQL Change Automation project, or if you are usi...
You'll be glad to know that we've just released SQL Source Control 7.0.6 to Frequent Updates which contains a fix for the invisible button problem. You'll need to enable frequent updates to see this update. / comments
You'll be glad to know that we've just released SQL Source Control 7.0.6 to Frequent Updates which contains a fix for the invisible button problem. You'll need to enable frequent updates to see thi...
Do you also have SQL Prompt installed? This might be a clash with older versions of SQL Prompt, and if it is, upgrading to the latest Prompt might help. / comments
Do you also have SQL Prompt installed? This might be a clash with older versions of SQL Prompt, and if it is, upgrading to the latest Prompt might help.
Yes, you can safely delete everything in the Caches directory. These shouldn't grow indefinitely, unless you're doing lots of linking/unlinking. / comments
Yes, you can safely delete everything in the Caches directory.These shouldn't grow indefinitely, unless you're doing lots of linking/unlinking.
That's correct, the blue change indicators only show when objects in the database have changed since the last time a commit/get-latest operation took place. The change tracking does not do a comparison with the linked version control system - that comparison only happens when you refresh the commit/get-latest tabs. / comments
That's correct, the blue change indicators only show when objects in the database have changed since the last time a commit/get-latest operation took place. The change tracking does not do a compar...
That's also why the shared model isn't really compatible with Git, because each developer has their own local repository which can change independently of any central remote you might have configured. / comments
That's also why the shared model isn't really compatible with Git, because each developer has their own local repository which can change independently of any central remote you might have configured.
If you're not using Object Locking, you can just drop the trigger. See https://documentation.red-gate.com/soc6/common-tasks/lock-an-object/remove-object-locking / comments
If you're not using Object Locking, you can just drop the trigger. See https://documentation.red-gate.com/soc6/common-tasks/lock-an-object/remove-object-locking
Git branches apply to the entire repository. If you want to branch and version each database independently, I'd suggest using a separate repository per-database. Git repositories are cheap and easy to create. / comments
Git branches apply to the entire repository. If you want to branch and version each database independently, I'd suggest using a separate repository per-database. Git repositories are cheap and easy...