There are
Seven Rules for Well-Behaved Primary Keys:
1)
Universal: Every row has a value in that column; not null.
2)
Unique: No two rows can share the same value
3)
Short as possible while preserving uniqueness: The shorter the possible, the less space it takes to store in the PK column, then the savings are multiplied by each of the foreign key (FK) references.
4)
Numeric: Numeric values take roughly half the storage space as beyond-numeric values. Numeric, by definition means shorter, thus supporting Rule #3.
5)
Not subject to change: If a PK value must change, then all of the FK references must change, as well. Avoidable change is a processing waste.
6)
"Ours": You do not want to use someone else's PK scheme...If their scheme changes, so must your scheme, thus breaking Rule #5.
7)
"Stupid": Good Primary Keys should not be intelligent. Specifically, they should not contain intelligence or have any special meaning...Meanings can change, therefore again breaking Rule #5.
I'm guessing ("betting" actually), that, at minimum your Primary Keys are disobeying Rules 2, 5, and 7; they very possibly also disobey Rules 3, 4, and 6.
These rules are in place to avoid the very problems that you are encountering. Said another way, If you follow these rules, you will not have the problems you are having. "Rules are our friends."
Now, since I have been accused of being rather dogmatic about good-design rules, and not helping people when their poor designs disobey rules of good design, I'll offer some help with your problem:
1) Apparently, you are attempting to give a row a Primary Key value that matches another exiting Primary Key value on another row in your table (thus disobeying Rule 2, above). Therefore, if you have your heart set about giving the new row the value of another PK in your table, you must first change the other PK value (
and all of the FK values referenced in its child tables, as well) to a unique PK value.
2) Then you can successfully change the current row's PK value (
and all of the FK values referenced in its child tables, as well).
My blood pressure just went up 50 points by my actually making this abhorrent suggestion.
Let us know what you decide.
![[santa] [santa] [santa]](/data/assets/smilies/santa.gif)
Mufasa
(aka Dave of Sandy, Utah, USA)
[
Providing low-cost remote Database Admin services]
Click here to join
Utah Oracle Users Group on Tek-Tips if you use
Oracle in
Utah USA.