I added a bunch of foreign keys to the database project when previously there weren't any. In the generated sql file (sql/debug/$projectname.sql) I see a part that starts with
PRINT N'Checking existing data against newly created constraints';
GO
USE [$(DatabaseName)];
GO
ALTER TABLE [dbo].[table1] WITH CHECK CHECK CONSTRAINT [FK_1];
ALTER TABLE [dbo].[table1] WITH CHECK CHECK CONSTRAINT [FK_2];
and on it goes.
How can I stop the database project from generating this section that checks the data against the new constraints? I tried creating the foreign keys using
ALTER TABLE dbo.table1 WITH NOCHECK
ADD CONSTRAINT [FK_1]
FOREIGN KEY (blah)
REFERENCES Table2 (blah2)
but no dice. Any suggestions?
Aha, there's an advanced option called checkNewConstraints in the Database.sqldeployment properties page under the properties folder. That should do the trick.
In VS 2019, you can find it as given in screenshot below. Uncheck the "Script validation for new constraints".
Right click your project and you will find Publish in the context menu. That will open up the Publish Database dialog. Follow 1, 2, and 3 (uncheck this option) and you will be able to get through the validation of existing data in the table for constraint checks.
Related
On extension update, instead of using update SQL schema I have given a custom button like fix database under that extension. It working fine. Custom script executes from same schema folder structure i.e. "/sql/updates/mysql"
But some DDL commands are not working like INSERT, ALTER for adding primary key for already existing table, DROP to delete table.
I have checked the MysqlChangeItem.php file (using Joomla 3.8.10) under "libraries/src/Schema/ChangeItem" & found the different DDL commands which are handled but does not found about INSERT/adding primary key for existing table/drop table.
Can you please suggest the solution
While generating the Create DB script for the existing Foreign Key constraint through SSMS, we could able to see two set of alter statements. one with NOCHECK ADD and another with CHECK.
ALTER TABLE [dbo].[claim] WITH NOCHECK ADD CONSTRAINT [FK_CLAIM_COPCID]
FOREIGN KEY([copcid])
REFERENCES [dbo].[copc] ([CopcId])
GO
ALTER TABLE [dbo].[claim] CHECK CONSTRAINT [FK_CLAIM_COPCID]
GO
Why we are getting two set of scripts to create a new Constraint?.
The first alter statement is creating a constraint and instructing that constraint to be added without checking whether the existing rows obey the new constraint.
When you add a constraint without first checking the rows, it will not be fully active until you enable it. That's what the second statement does, it enables the new constraint. If there are rows that break the constraint, you won't be able to enable it.
In my table I have primary key on 3 columns (name, dept, MobNo).
Now I want to change it to be on two columns (Name, MobNo).
Is there any way I can alter the primary key constraint without dropping it?
I know I can drop old constraint and can create new but without dropping old constraint it is possible to alter it?
The only and one way would be to drop the constraint with an Alter table then recreate it.
ALTER TABLE <Table_Name>
DROP CONSTRAINT <constraint_name>
ALTER TABLE <Table_Name>
ADD CONSTRAINT <constraint_name> PRIMARY KEY (<Column1>,<Column2>)
If you (probably) have dependencies on that PK, you will also have to drop them and recreate them. To have all this done automagically, it's easier from SSMS to right-click on the table, choose Design, and from there you click in the top left toolbar the button called Manage indexes and Keys. From there you make your changes, and at the end, you have 2 options:
you close and save your changes (and it works fine but you don't learn anything)
instead you click on the Generate change script so you can examine and execute the script later
(at least it works like this with my version 2014 of SSMS)
I'm trying to update a target database with SQL Server Data Tools, using the Publish option. I've got both pre-deployment and post-deployment scripts with custom instructions.
Here's the problem: SSDT tries to drop an index numero from my target that doesn't exist in my reference schema, but fails because it is being used for foreign key enforcement by constraint fk_numero. This foreign key is being dropped later in the script since there's another change to be made on this table.
I have considered dropping fk_numero in my pre-deploy script, but it would fail anyway because of the DROP CONSTRAINT fk_numero that is called later in the generated script: since SSDT doesn't write IF EXISTS tests before dropping a constraint, it fails when trying to delete something that doesn't exist.
I have also tried to disable all foreign keys in my pre-deploy script with a NOCHECK CONSTRAINT ALL, hoping I'd then be able to drop my index, to no avail.
Is there an option in SSDT to specify whether you want it to generate DROP CONSTRAINT scripts? Or an option for instructions order? Or a way to hint to SSDT that it should test whether the constraint exists before trying to drop it?
You could try the "DROP objects in target but not in Project" option.
Are you using custom-made scripts to modify the schema?
I just encountered this issue when working with SSDT. Turns out it's a known bug, which was reported on Microsoft Connect. However, it doesn't seem to have been resolved.
UPDATE:
The May 2015 Update for SSDT includes a fix for this issue.
I wanted to modify a column in a sql server 2005 table to IDENTITY(1,1)
Incidentally this table is empty and the column to be changed is a primary key.
This column is also a foreign key for two other tables.
After googling I found that you cannot use Alter table syntax to modify a column and make it an indentity column.
Link #1 : How do I add the identity property to an existing column in SQL Server
Link #2 : Adding an identity to an existing column -SQL Server
I ended up checking the dependent tables (2 of them) removing the foreign keys (generated the script from SSMS) then dropping the main table then re-creating with identity. (could try the rename option here as well)
Then re-created the foreign keys for the earlier dependent two tables.
But all this was manual work, any scripts or SPs out there to make this easier.
Ideally all these steps would be done by such a script/tool/utility:
Check dependent tables keys
Generate Create and drop foreign key scripts for this
Generate create script for the main table
drop the main table (or rename the table if the table has data)
re-create the table with identity column enabled
re-create foreign keys
You can use SSMS to generate a script (Edit a table, save script), but otherwise it's a manual process as you identified.
The SSMS scripts will pick up dependencies etc. For this kind of work, I tend to use SSMS to generate a basic script, pimp it a bit, run it carefully, then use a comparison tool (such as Red Gate compare) to generate a safer version.
Edit: The SSMS error is not an error, it's a safety check that can be switched off
(This is merely a follow-up to gbn's post with more details -- it isn't all that easy to figure this stuff out.)(
It isn't impossible to write a utility to do this, just very complex and very hard. Fortunately, Microsoft has already done it -- its called SSMS (or SMO?). To generate such a script:
In the Object Explorer, drill down to the database and table that you want to modify
Right click and select Design
Make the desired changes to the one table in the design screen. It's reasonably intuitive.
To add/remove the identity property, select the column in the upper pane, and in the lower pane/"Column Properties" tab, expand and configure the settings under "Identity Specification".
To generate a script to implement all your changes, incorporating all the dependent key changes, click on the "Generate Change Script" toolbar button. This is also an option under the "Table Designer" menu.
I also do this to generate scripts (that I later modify--SSMS doesn't always produce the most efficient code.) Once done, you can exit out without saving your changes -- leaving you a DB you can test your new script on.
drop the pk and build the same datatype column
copy the data of the column which you want to set identity to the new column.
drop the old column
reset primary key
ALTER TABLE UserRole
DROP CONSTRAINT PK_XX
ALTER TABLE XX
ADD newX int not null identity(1,1) primary key
update XX set newX = oldX
alter table XX
DROP COLUMN oldX
this is the simplest way to set identity column.
if you don't want to use the long generated script.