Celebrate National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Update of Primary Key oft times not successful

Posted on 2007-11-30
Medium Priority
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.
@Old_CustomerID varchar(15),
@New_CustomerID varchar(15),
@Return_code int output
declare @sql nvarchar(4000)
SET @Return_Code = 1
/* If old customer ID is found, update it to the new customer ID */
    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
    SET @Return_Code=0
SELECT @Return_Code

Open in new window

Question by:rwheeler23
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2
  • +1

Accepted Solution

wittyslogan earned 750 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

Expert Comment

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.
LVL 23

Expert Comment

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...
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Expert Comment

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" : )

Expert Comment

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.
LVL 23

Expert Comment

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

Expert Comment

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..


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.

Author Comment

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?

Expert Comment

ID: 20397840
i supppose you could set identity insert off.


insert customer number into table


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.

LVL 23

Expert Comment

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...

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

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

Ever needed a SQL 2008 Database replicated/mirrored/log shipped on another server but you can't take the downtime inflicted by initial snapshot or disconnect while T-logs are restored or mirror applied? You can use SQL Server Initialize from Backup…
Windocks is an independent port of Docker's open source to Windows.   This article introduces the use of SQL Server in containers, with integrated support of SQL Server database cloning.
Via a live example, show how to backup a database, simulate a failure backup the tail of the database transaction log and perform the restore.
Viewers will learn how to use the SELECT statement in SQL and will be exposed to the many uses the SELECT statement has.

730 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