Comments
Sort by recent activity
Hi @Alex B, This was version 13.7.3.9483. I've just replicated it with a similar test table, using a varchar(15) instead of an int for the primary key column: BEGIN TRANSACTION
GO
IF @@ERROR <> 0 SET NOEXEC ON
GO
PRINT N'Dropping constraints from [dbo].[TestTable]'
GO
ALTER TABLE [dbo].[TestTable] DROP CONSTRAINT [PK_TestTable]
GO
IF @@ERROR <> 0 SET NOEXEC ON
GO
PRINT N'Altering [dbo].[TestTable]'
GO
IF @@ERROR <> 0 SET NOEXEC ON
GO
ALTER TABLE [dbo].[TestTable] ALTER COLUMN [EntryCode] [varchar] (15) NULL
GO
IF @@ERROR <> 0 SET NOEXEC ON
GO
PRINT N'Creating primary key [PK_TestTable] on [dbo].[TestTable]'
GO
ALTER TABLE [dbo].[TestTable] ADD CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED ([EntryCode])
GO
IF @@ERROR <> 0 SET NOEXEC ON
GO
COMMIT TRANSACTION I've just done a check for updates but SQL Compare thinks it is up to date already. Kind Regards, Xander / comments
Hi @Alex B,This was version 13.7.3.9483. I've just replicated it with a similar test table, using a varchar(15) instead of an int for the primary key column:BEGIN TRANSACTION
GO
IF @@ERROR <> 0 SET...
Hi @Alex B Ah, I've just figured it out. Ignore indexes was the problem, since obviously a primary key is an index. Perhaps a warning is needed when ignoring indexes is going to generate a script that can't complete? Thanks for the help! / comments
Hi @Alex B Ah, I've just figured it out. Ignore indexes was the problem, since obviously a primary key is an index. Perhaps a warning is needed when ignoring indexes is going to generate a script t...
Hi @Tianjiao_Li, Brilliant! Thanks so much for your help and ensuring the bug was fixed [image] We have since bought SQL Compare and are using it a bit more. I have a quick question I hope you could resolve. The columns listed in the grid when comparing 2 DBs are great, but I was wondering if these were customisable at all. Specifically I was hoping to have a column showing the difference in days between the last modified dates on each database. We sometimes have a case where the 2 DBs being compared have both had updates the other hasn't had, so a column where I could see the day difference, especially showing a negative or positive number, would be very helpful. Thanks again. / comments
Hi @Tianjiao_Li,Brilliant! Thanks so much for your help and ensuring the bug was fixed We have since bought SQL Compare and are using it a bit more. I have a quick question I hope you could resolve...
@Tianjiao_Li Any news with this bug? / comments
@Tianjiao_Li Any news with this bug?
Hi Tianjiao, I've just restored your DBs and looked at the row you added to the Tenancy table on the target, and you didn't actually leave any columns as NULL, but rather empty string. So the deployment succeeds for me like that, but if I change the [Use ERV Say] column to NULL, I get the same failure: [image] All SQL Compare needs to do is change the order it generates the statements for the deployment script, and it would work fine. / comments
Hi Tianjiao,I've just restored your DBs and looked at the row you added to the Tenancy table on the target, and you didn't actually leave any columns as NULL, but rather empty string. So the deploy...
Tianjiao_Li said:
@Xander I've reproduced the issue and logged in our internal bug tracking system whose reference number is SC-10262! Thanks for helping us with the reproduction and your patience is much appreciated!
Hi Tianjiao, It's great to hear you've been able to replicate it. I'm surprised this hasn't come up before as it doesn't seem like an exceptionally uncommon case for SQL databases to have a column that was once NULL-able to become not NULL-able. Is there any way for me to track the bug? This was one of the big things that stopped my company from purchasing SQL Compare so would be great to see when it gets fixed. Thanks. / comments
Tianjiao_Li said:
@Xander I've reproduced the issue and logged in our internal bug tracking system whose reference number is SC-10262!Thanks for helping us with the reproduction and your pati...
Hi Tianjiao, That really isn't necessary... I've just replicated the bug myself on 2 newly created databases. I've just created a TestSource and a TestTarget DB, applied the create table statements I gave you, added a row of data into the TestTarget DB where I left [Use ERV Say] as NULL, and I get the exact same failure. [image] Because the script doesn't try to add the default until after setting the column to NOT NULL, the column is still NULL for that row and the update fails. All the script needs to do is put this one before the other two: ALTER TABLE [dbo].[Table] ADD CONSTRAINT [DF_Table_Column] DEFAULT ('F') FOR [Column]But as is this tool is unfortunately useless for databases with any data in the tables... / comments
Hi Tianjiao,That really isn't necessary... I've just replicated the bug myself on 2 newly created databases. I've just created a TestSource and a TestTarget DB, applied the create table statements ...
[image] This is what happens when I try to deploy. It would work perfectly if the ADD CONSTRAINT statement was executed before the other two, but as is the script tries to replace NULLs with a default that doesn't exist, so it will never succeed. / comments
This is what happens when I try to deploy.It would work perfectly if the ADD CONSTRAINT statement was executed before the other two, but as is the script tries to replace NULLs with a default that ...
I've just sent you a PM with the scripts. I think you'll need to add some data to the target table after creating it, leaving at least one of the columns NULL that can be NULL on the target but not on the source. [Use ERV Say] is a good example column. Thanks. / comments
I've just sent you a PM with the scripts.I think you'll need to add some data to the target table after creating it, leaving at least one of the columns NULL that can be NULL on the target but not ...
Hi Tianjiao, I was on version 13.4.5.6953 but just upgraded to the one you linked (13.5.0.7565) and I'm encountering the same problem. In your screenshot you've shown the deployment script is adding the default constraint, which mine is doing too, but it's trying to add it too late. The order the script is generated means it tries to replace nulls with the default (which does nothing, because there is no default), then tries to change the column to not null, then adds the default. Because the nulls weren't replaced, the script fails when it tries to change the column to not null. / comments
Hi Tianjiao,I was on version 13.4.5.6953 but just upgraded to the one you linked (13.5.0.7565) and I'm encountering the same problem.In your screenshot you've shown the deployment script is adding ...