Can we drop and recreate primary key in SQL Server table # Production environment? Do we have to down the server for it or we can do it live? - sql

Can we drop and recreate a composite primary key in a SQL Server table in production environment? Do we have take down the server for it, or can we do it live?
Because we have to add more columns to the primary key. If we done it in live what are the problems we have to face?

You can remove primary key from table.This will also remove clustered index of that table if you have't mentioned explicitly on other column.
To remove primary key run below query
-- Drop CHECK CONSTRAINT from the table
ALTER TABLE /*schema*/./*table*/
DROP CONSTRAINT /*constraint_name*/
GO
and to add primary key run below code
-- Add a new CHECK CONSTRAINT to the table
ALTER TABLE /*schema*/./*table*/
ADD CONSTRAINT /*contraint_name*/ /*constraint_type*/ (/*constraint_column_name*/ /*logical_expression*/)
GO

Related

Alter table in impala : make a column a primary key

Using Hue, how can I alter a table to make a prexisting column a primary key?
I check and things like :
ALTER TABLE table_name ADD CONSTRAINT colname PRIMARY KEY (cs_id);
is not syntactically correct.
NB: data is stored using Kudu file system.
First, Impala does not support alter contraint as an option in alter table.
Second, primary keys are very limited:
The primary key columns must be the first ones specified in the CREATE TABLE statement.
I don't think you can change the primary key after it has been defined. In Impala, the data is clustered (i.e. sorted) by the primary key, so any change would be quite expensive.
You probably need to recreate the table and reload it with data.
When you are storing as Kudu, you need to consider that the PK columns need to be all created at the creation of the table.
Impala does not support altering primary keys.
I'm afraid you need to delete and create the table again.

Inserting new record and skip if foreign key conflict in sql server 2008 R2

I have the problem similar to this one SQL Server foreign key conflict in a multi values statement? However, in sql server 2008.
While I am reading data from csv file, there is some id already not exist in parent and thus return this error:
INSERT statement conflicted with the FOREIGN KEY constraint
May I know if there is a way similar to MySQL insert ignore. Such that I can simply skip the problematic data.
I accept that if there is no method other than creating a stored procedure with a new temp table (insert into a table without foreign key first, and then re-insert with where foreign_id exists in (select id from parent)).
As I really cannot find any in documentation, asking for ensuring I didn't miss anything.
One general solution which comes to mind would be to temporarily turn off the foreign key constraints, and do the insert. Then, afterwards, you may run a cleanup script/query to remove or rectify child records which are pointing to parents which do not exist. Once your data is in good shape, then turn on the foreign key constraints again.
Read How can foreign key constraints be temporarily disabled using T-SQL? to learn how to disable/enable a foreign key constraint for a single table:
ALTER TABLE MyTable NOCHECK CONSTRAINT MyConstraint -- disable
ALTER TABLE MyTable WITH CHECK CHECK CONSTRAINT MyConstraint -- enable

Generating Create script for existing foreign key through SSMS

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.

Alter Primary key constraint

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)

Modify existing Foreign Key to include Update Cascade

I'm using SQL Server 2008 R2 & SQL Azure database for my environment. I have defined primary keys and foreign keys and their constraint names too. I now want to change the primary key values but I cannot do it since the foreign keys not allowing me to do since they are not specified as UPDATE CASCADE when the PK-FK relationship / constraints were defined.
Is there any SQL statement by which in the existing constraints I can include the UPDATE CASCADE and henceforth change my primary key values?
As far as I know, you can only define those attributes like ON UPDATE CASCADE when you create the constraint.
So you'll need to drop the constraint and re-create it with the proper attributes.
If you need to drop the primary key constraint, you'll have to
drop all FK constraints referencing that PK
then drop and re-create your PK constraint
and in the end, re-create the dropped FK constraints