Comments
Sort by recent activity
The SQLChangeAutomation tasks download the latest version of SQLChangeAutomation from the PowerShell gallery on each run of the build. There is no harm in deleting them all and we would usually expect them to be cleaned up before each build as part of the agent configuration. Cleaning up the checkout directory before each build is a build-server configuration and not related to SQL Change Automation. It is usually located in the VCS part of the build configuration. I am afraid I do not have TFS to hand to check the exact details. / comments
The SQLChangeAutomation tasks download the latest version of SQLChangeAutomation from the PowerShell gallery on each run of the build.There is no harm in deleting them all and we would usually expe...
PowerShell 7 is not yet supported unfortunately. Some work has been done towards it and we will likely do some more investigations into supporting it in the near future. It is definitely on our radar. We are currently limited to PowerShell 5. / comments
PowerShell 7 is not yet supported unfortunately. Some work has been done towards it and we will likely do some more investigations into supporting it in the near future. It is definitely on our rad...
Hi, It is still very much on our radar and some further progress has been made towards it. Updating to PowerShell 7 requires moving all our code to support net core. Much of that is done but it requires work from multiple teams as our PowerShell components support a number of different integrations. / comments
Hi,It is still very much on our radar and some further progress has been made towards it.Updating to PowerShell 7 requires moving all our code to support net core. Much of that is done but it requi...
Many apologies. I had though that this was released in yesterday's release, which was indeed 4.2.20057.15888. We have just released again, version 4.2.20058.15937, and the issue should now be fixed. Apologies again. / comments
Many apologies. I had though that this was released in yesterday's release, which was indeed 4.2.20057.15888.We have just released again, version 4.2.20058.15937, and the issue should now be fixed....
This is an issue we have recently discovered and fixed. This is fixed in the latest release (4.2.20056). The workaround in the existing release is to manually set the shadow database in the user file. e.g.<ShadowConnectionString>Data Source=(localdb)\ProjectsV13;Initial Catalog=MyShadowDatabase;Integrated Security=True</ShadowConnectionString> / comments
This is an issue we have recently discovered and fixed. This is fixed in the latest release (4.2.20056).The workaround in the existing release is to manually set the shadow database in the user fil...
When the baseline script is generated, nothing is written to the target database used for the baseline. It is safer for that to be a read-only operation. Users might need to edit the baseline script, or associated programmable objects, before proceeding. The consequence of this is that we have no concrete record of the database state used to generate the baseline, so don't really have a simple basis upon which to mark the programmable objects as applied rather than adding them to the script. There is a flag, "BaselineAllDeployChangesMigrations", which can be used to mark all programmable objects as applied instead of deploying them, but it should be used with caution, as it only makes sense when deploying the baseline and nothing more. Currently the only way of setting it is by adding <BaselineAllDeployChangesMigrations>True</BaselineAllDeployChangesMigrations> to the project file. It needs to be set to false (or removed) for any subsequent changes to the programmable objects to be handled correctly. Hacking it by copying across the __MigrationLog table should work. / comments
When the baseline script is generated, nothing is written to the target database used for the baseline. It is safer for that to be a read-only operation. Users might need to edit the baseline scrip...
Hi, Just to qualify this. When a release artifact is generated only the programmable objects which have not been deployed should be included in the release artifact script. If it is the very first deployment to the target database, then the __MigrationLog table will not yet exist in the target database, so these scripts will be included in the deployment script, as they will not yet have been marked as deployed. / comments
Hi,Just to qualify this. When a release artifact is generated only the programmable objects which have not been deployed should be included in the release artifact script.If it is the very first de...
Thank you very much for your feedback and apologies for the frustration caused by this behaviour. In both cases the operation is notionally the same. We only regenerate the shadow database if necessary. If we do, the operation will potentially take significantly longer. The experience would definitely be improved if we had some more granular progress indications which provided more information on what is going on under the hood. This is definitely something that we will consider adding. / comments
Thank you very much for your feedback and apologies for the frustration caused by this behaviour.In both cases the operation is notionally the same. We only regenerate the shadow database if necess...
There are some other options: You could define the relevant programmable objects in the relevant migration as well. This has to be done manually. You can then still keep on using the programmable objects in their separate files as before. Note that if you baseline an existing database, this will happen automatically for the baseline script See the following page for handling some programmable object dependency issues: https://documentation.red-gate.com/sca/developing-databases/concepts/baseline/resolving-unsupported-programmable-objects.. If it is safe to drop and recreate these objects outside of migrations, you can instead either manually handle them as additional scripts (https://documentation.red-gate.com/sca/developing-databases/concepts/migrations/additional-scripts) or you can configure them to be treated as programmable objects (by editing DeployChangesImportObjectTypes - see https://documentation.red-gate.com/sca/reference/sql-change-automation-project-settings) / comments
There are some other options:You could define the relevant programmable objects in the relevant migration as well. This has to be done manually. You can then still keep on using the programmable ob...
Hi, We are very sorry you are experiencing this issue. We are investigating as a matter of urgency and will let you know once the issue is resolved. / comments
Hi,We are very sorry you are experiencing this issue.We are investigating as a matter of urgency and will let you know once the issue is resolved.