Activity overview
Latest activity by MGibson
Query processor could not produce a query plan because of the hints defined in this query.
I am getting this error when running dynamic sql with the forceseek query hint.
Moving columns without using migration scripts
What is the best way to move a column and preserver data without using migration scripts?
PRINT N'Creating extended properties' GO IF EXISTS(SELECT 1 FROM sys.system_views sv WHERE sv.name = N'sensitivity_classifications') BEGIN RAISERROR('To deploy sensitivity classification information to this platform, the ADD SENSITIVITY CLASSIFICATION syntax should be used.', 16, -1) SET NOEXEC ON END GO / comments
PRINT N'Creating extended properties'GOIF EXISTS(SELECT 1 FROM sys.system_views sv WHERE sv.name = N'sensitivity_classifications')BEGIN RAISERROR('To deploy sensitivity classification informatio...
Deploying extended properties to Azure and the sql generated is raising an error
Error raised is To deploy sensitivity classification information to this platform, the ADD SENSITIVITY CLASSIFICATION syntax should be used.
SQL Compare latest production version not comparing encrypted stored procedures in Azure SQL DB
This comparison works fine in SQL Server 2016/17.
After communicating with support, the work around does not work for us, as this problem exists for many of our migration scripts and for any new migration that we create.
Therefore we currently cannot create any new migration scripts without this defect being fixed.
What that means for us in the case of moving a non-nullable column to a different table as an example;
1. We add the new column as nullable and check this in.
2. We populate the data in the new column from the old one in a post deployment script which runs after all the other processes have completed in our CI.
3. We raise a JIRA for the next release cycle to remove the old column and make the new column non-nullable, which will involve another post deployment fix to ensure there are no null values.
This means we are shipping a half way change to production and this will become very complex for major database refactoring work, which we are about to embark on for some parts of our system.
I cannot emphasis enough how important this defect fix is to us.
If possible I would like to discuss this with someone at Redgate over the phone.
Thanks / comments
After communicating with support, the work around does not work for us, as this problem exists for many of our migration scripts and for any new migration that we create.
Therefore we currently can...
Hi Mike
The workaround did not work. I added the sql as you said in out pre-deployment and got the same error as before about the duplicate trigger.
Please advise. / comments
Hi Mike
The workaround did not work. I added the sql as you said in out pre-deployment and got the same error as before about the duplicate trigger.
Please advise.
Can I confirm the workaround? You want us to mark the migration script that is causing the error as deployed by running the sql you have provided against the target database. This begs the question, what is the point of adding the migration script in the first place if it is not going to be run. The fact that I have created the migration script means there is a data change I want to run to move data from the old to the new column, After running the migration script I want to delete the old columns, in the same build iteration as adding and populating the new column. Please confirm what we have to do here?
If we cannot run the migration script, we are going to have to populate the new column in a post deployment script, and then remove the old column in a later iteration, which is far from ideal and leads to us deploying code that is sub-optimal to work around a defect in your software.
If the workaround works as I have described, can I strongly suggest this bug is treated as high priority, This one defect has caused us huge problem in our development process, and was first raised to you months ago. We have been going back and forward trying to work out what the problem was, and trying different solutions. / comments
Can I confirm the workaround? You want us to mark the migration script that is causing the error as deployed by running the sql you have provided against the target database. This begs the question...
Any support ticket we have on this issue was raised by a developer who is now on holiday. Please can I have a link to the support ticket you are referring to. / comments
Any support ticket we have on this issue was raised by a developer who is now on holiday. Please can I have a link to the support ticket you are referring to.
Hi Mike
Just to confirm, the Category table that is producing the error has a before and after trigger.
The migration script does not attempt to change data in the Category table. / comments
Hi Mike
Just to confirm, the Category table that is producing the error has a before and after trigger.
The migration script does not attempt to change data in the Category table.