I know what all the long-time WO users (not mentioning general DB
users) will be thinking - "the pk's are for the database to use, not
the users". I believe everyone would advise *strongly* not to have the
pk's modified by the users. It makes things hard enough just having a
meaning attached to them.
However, having said all that, if you really have "no option" about
this (and there is always an option, even if not desired) then I would
expect that each time a user wanted to change a value that was linked
to a pk, you would need to change the pk in question (most probably by
creating a new record to replace your old one as you mentioned) but
also need to go through all linked tables and change the foreign keys
to match the new value as well.
Would it not be possible to add another attribute/field which simple
duplicates the existing pks, but splits the role of the current ones
into true pk's the db can use, and nominal numbers the users can use?
r
On 28/09/2004, at 3:12, Benjamin Adair wrote:
Morning all.
I, understandably, am getting errors attempting to update the primary
key of an EO. This is a situation where the PK is a meaningful
attribute, yet must be user modifiable. (I am fitting a WO app to an
existing system that drives our web site. Changing it to work with WO
is not possible -nor should it be required in my idealist's world. Ah,
the life of the idealist..)
What have others done to work around this? Turning off the PK
attribute in the EOModel gives errors were EOAccess expects the entity
to have a PK. The only solution that comes to mind is to watch for
when the user has modified the PK and manually insert what is
essentially a brand new row and delete the old. Is there a simpler
solution? If it's there in the API, I'd appreciate a quick pointer
where to look, though I didn't see anything obvious from what I've
seen so far.
