Comments
Sort by recent activity
You can set DriftOptionBlockDataLoss as a property in your .sqlproj file for your SCA project. See https://documentation.red-gate.com/sca3/automating-database-changes/automated-deployment-with-sql-change-automation-core/continuous-integration-msbuild and scroll down to 'Drift report and drift correction script' for more information. The property should then take effect for all deployments of the project, including in VSTS. / comments
You can set DriftOptionBlockDataLoss as a property in your .sqlproj file for your SCA project. See https://documentation.red-gate.com/sca3/automating-database-changes/automated-deployment-with-sql-...
Hello Sorry you're still experiencing this issue. If you contact Redgate support at support@red-gate.com we can assist you further. Our support system provides a mechanism for uploading large files. Thanks / comments
HelloSorry you're still experiencing this issue. If you contact Redgate support at support@red-gate.com we can assist you further. Our support system provides a mechanism for uploading large files....
Hello Sorry you're encountering problems with SQL Change Automation. First, try updating to the latest version of the SQL Change Automation Visual Studio Extension. If that doesn't work, please contact support@red-gate.com. If you can prepare a zipped folder containing the project that's crashing also. This will help us debug the problem and find a solution for you. In the meantime, it's possible to recover your progress even if the project cannot be loaded. First, you can create a new project and connect to your development database that has the changes. Second, you can copy the migration scripts from your existing project into a new one. Thanks / comments
HelloSorry you're encountering problems with SQL Change Automation.First, try updating to the latest version of the SQL Change Automation Visual Studio Extension.If that doesn't work, please contac...
Hello If SQL Change Automation doesn't recognize the deletion of a PO then you'll have to manually delete the object from your development DB.
In the target database, drop the PO (e.g. using SSMS or the SQL Server Object Explorer in Visual Studio)
In the SCA tool-window, import the change from the target database by clicking Import and Generate Script (This will generate a migration to drop the PO, and also remove the contents of the PO script from the project)
Optionally, delete the empty PO file from the project
Thanks / comments
HelloIf SQL Change Automation doesn't recognize the deletion of a PO then you'll have to manually delete the object from your development DB.
In the target database, drop the PO (e.g. using SSMS or...
Hello It's perfectly fine to upload the NuGet package using any mechanism you wish. You can use `Export-DatabaseBuildArtifact` to export an then publish any way you want. As you guessed, we use an embedded client and call just `nuget push`. Thanks / comments
HelloIt's perfectly fine to upload the NuGet package using any mechanism you wish. You can use `Export-DatabaseBuildArtifact` to export an then publish any way you want.As you guessed, we use an em...
Hello Tom In my opinion the simplest way to help avoid problems like this is to take an approach where the main branch must always be shippable. In order to ensure that your main branch is always shippable, it's important to have a manual review step before changes are introduced to your main branch. This can be achieved by doing work on separate branches, then merging into the main branch only when the work is finished and has passed review. This ought to prevent the scenario where Test and Prod changes are introduced to the version to be shipped to customers. The next step is to set up a Continous Integration process. The CI proces should do things like verify the schema of the main branch, and run T-SQL tests. This should be done automatically whenever the main branch is pushed to the remote repository. The SQL Change Automation documentation explains how to do this: https://documentation.red-gate.com/sca3/automating-database-changes/continuous-integration. These processes ought to alert you to problems earlier on in your development process. CI is of course a large area and there's many opnions on how to set things up. I can point you to a couple more articles for further reading: https://dri.es/always-be-shippable https://www.red-gate.com/hub/product-learning/sql-change-automation/moving-from-application-automation-to-true-devops-by-including-the-database Thanks Mikiel / comments
Hello TomIn my opinion the simplest way to help avoid problems like this is to take an approach where the main branch must always be shippable.In order to ensure that your main branch is always shi...
Hello Rick Are you able to provide more information about your build? Specifically can you include the log of the failed build? Thanks / comments
Hello RickAre you able to provide more information about your build? Specifically can you include the log of the failed build?Thanks