If your primary key can be changed on a record, I would suggest using a surrogate key myself. I know there's a fair debate on using surrogate keys, but using a surrogate key will allow you to change the value of your "primary key" freely without affecting relational data.
Put a unique index on it if you want to ensure that it'll stay unique.
Not an easy thing to change if you're far along down the line, necessarily. But your primary key shouldn't really be changing after creation (or minimally shouldn't change often) IMO.
skagen00:If your primary key can be changed on a record, I would suggest using a surrogate key myself.
This is what I am doing on my end. Create a property called UniqueKey.
On Fetch assign
UniqueKey = various composites values coming from db
On the insert and just after the sql cmd
UniqueKey = various composites values
On the Update
update cmd and use in where clause the
various composites coulmns = UniqueKey
assign again after the sql update to the latest values in case any of various composites values
UniqueKey = various composites values
In addition, the SQL table should have a unique index key as the other users pointed out to have good valid data. Otherwise you will have to check every time you do an insert and update so you do not have dup ukeys.
Hope it helps
frankhoffy:
Tell that to my DBA
<quote>
Tell that to my DBA
</quote>
Ouch. Informationless keys are your friend. Did he give you any justification behind his decision?
Thanks,
Kevin
Copyright (c) Marimer LLC