asked on

Update of Primary Key oft times not successful

I have embedded Dynamics SQL update commands in my application. One such task is responsible for updating 28 tables that contain a field containing the customer number field. It has come to my attention that for 3 of the tables the update is not successful even though the status code that comes back indicates success. The unique characteristic to these three tables is that the customer number field is the primary key. How can I best trace this to attempt to determine why my update is failing or perhaps if my update succeeds but then is rolled back? This is MS SQL Server 2005.

CREATE PROCEDURE [dbo].[rbsUpdateSTAXINFO] 
@Old_CustomerID varchar(15),
@New_CustomerID varchar(15),
@Return_code int output
 
AS 
 
declare @sql nvarchar(4000)
SET @Return_Code = 1
/* If old customer ID is found, update it to the new customer ID */
IF EXISTS (SELECT * FROM STAXINFO WHERE rtrim(CUSTOMER_NUMBER_STXI)=rtrim(@Old_CustomerID))
BEGIN
    
    SET @sql = ' update STAXINFO ' +
               ' set CUSTOMER_NUMBER_STXI = ' + @New_CustomerID + 
               ' where CUSTOMER_NUMBER_STXI= @Old_CustomerID'
    exec sp_executesql @sql, N'@Old_CustomerID varchar(15)',@Old_CustomerID
  
END
ELSE
BEGIN
    SET @Return_Code=0
END
 
SELECT @Return_Code
 
RETURN 
 
GO

Open in new window

ASKER CERTIFIED SOLUTION

wittyslogan

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

usarian

You can change primary keys, but there are a lot of reasons why it would not work.

1) If your new value already exists in those three tables then the update will fail

2) If the CustomerID in those three tables references CustomerID in another table the update will fail

3) If the CustomerID in those three tables is referenced to from another table/column the update will fail

4) If there are triggers on those tables or some other table, or a scheduled job running every so often that ensures the "proper" value of that column, then the update could succeed or fail depending on the situation and still contain the original value.

Any number of constraints or automation could be at fault really.

Racim BOUDJAKDJI

<<This will fail as the primary key MUST remain the same and cannot be updated.>>
*MUST* seems like a strong word to me. It is not that a primary can't be updated bu rather that it should be as stable as possible...If an attribute subset is not stable, that probably means there is got to be a better one to select among canddate keys.

Hope this helps...

wittyslogan

sorry about that,
when I said MUST
what I meant to say was "if you want to spend a day unpicking a live database due to primary key problems and explain it in a way that means you'll still keep your job go right ahead" : )

wittyslogan

cheekiness aside.

If you are changing a primary key then it is not really a primary key. You should alter your table and put on a real primary key instead.

If you've got indexes hanging off a primary key that can be changed then you will get into terrible trouble in terms of performance. You will run into problems with primary key constraints as well.

Customers willl get letters containing details of someone else. This is happening right now in the UK. The letters people are getting to apologise for the loss of 25 milion personal records are going to the wrong people. And I bet that the people behind that change primary keys as well.

Racim BOUDJAKDJI

<<If you are changing a primary key then it is not really a primary key. You should alter your table and put on a real primary key instead.>>
or select a better primary key in existing columns (select another subset of attributes more stable) without having to an additional columns...

<<And I bet that the people behind that change primary keys as well.>>
The problem is even worse than a single incident (be it a massive blunder). Because of poor key selection, we also have dupplicate data allowed and therefore a lack of correctness in most count results...

My two cents

usarian

I had assumed the database was pre-existent and the intent was to make a one time change, or a one time group of changes after which the code would be mothballed.

If this other assumption is correct, that the database and application are being designed to cause frequent primary key updating..

DONT DO IT! IT'S A TRICK!

Yeah, seriously. Look at least at making an autoincrement column as a primary key and leaving it the heck alone after that. Indexes (a.k.a. indices) key off primary keys and all kinds of bad things are coming your way if you dont change your design now.

rwheeler23

ASKER

Hey folks, I need you to help an old guy out here. This is a 30 year old database that was born in Btrieve and migrated to MS SQL 10 years ago. I always wondered why when I look at a SQL table there is always this identity column designated as its primary key and then there are the rest of the indicies. All that happens here is that every now and then it is necessary to change a customer number. So the customer master record has to be updated along with all the sales order records that go along with that customer. With the sales orders, the customer field is not the primary key and they update without an issue. It is the master record that has trouble. Should I modify my customer record to include an identity column and make that the primary key? If so, how do I add an identity column to a table that already has record in it?

wittyslogan

i supppose you could set identity insert off.

SET IDENTITY_INSERT table_name OFF
GO

insert customer number into table

SET IDENTITY_INSERT ON

This turns off the identity column until you put in the data. The only thing is I would try to set it up so it only switches off the specific table. So I'd get the routine to loop through all you table and then carry the variable to a routine which just inserts into this table.
And only if nothing depends on this table. ie.when you say "Master" table you mean "archive".

And I'd test it in development.

ALTER TABLE I'd need to think about for a while. We would be looking at changing the structure.

Racim BOUDJAKDJI

Unless the 1:1 cardinality is implemented between the identity column and the subset of columns that identify the record by some kind of unique constraint that subset of columns, the identity column is more a pointer than a true primary key, even if SQL server calls it a primary key or identity. So make sure the unique constraint is implemented on the column subset in piority. That's what guarantees data integrity not the pointer called *identity*.

Hope this helps...