Solved

Update of Primary Key oft times not successful

Posted on 2007-11-30
10
1,379 Views
Last Modified: 2008-02-28
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

0
Comment
Question by:rwheeler23
  • 4
  • 3
  • 2
  • +1
10 Comments
 
LVL 7

Accepted Solution

by:
wittyslogan earned 250 total points
ID: 20383782
Are you try to update a primary key?
This will fail as the primary key MUST remain the same and cannot be updated.


If you have to update this number then I would suggest not having it as the primary key
0
 
LVL 5

Expert Comment

by:usarian
ID: 20383957
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.
0
 
LVL 23

Expert Comment

by:Racim BOUDJAKDJI
ID: 20384171
<<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...
0
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
LVL 7

Expert Comment

by:wittyslogan
ID: 20384561
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" : )
0
 
LVL 7

Expert Comment

by:wittyslogan
ID: 20384775
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.
0
 
LVL 23

Expert Comment

by:Racim BOUDJAKDJI
ID: 20386261
<<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
0
 
LVL 5

Expert Comment

by:usarian
ID: 20386400
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.
0
 

Author Comment

by:rwheeler23
ID: 20397626
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?
0
 
LVL 7

Expert Comment

by:wittyslogan
ID: 20397840
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.



0
 
LVL 23

Expert Comment

by:Racim BOUDJAKDJI
ID: 20397925
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...
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
This article shows gives you an overview on SQL Server 2016 row level security. You will also get to know the usages of row-level-security and how it works
Via a live example, show how to shrink a transaction log file down to a reasonable size.
Viewers will learn how to use the INSERT statement to insert data into their tables. It will also introduce the NULL statement, to show them what happens when no value is giving for any given column.

770 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question