>
>I understand your position. I used to do the same kinds of things. I
>have more recently come to the opinion that table primary keys should be
>internally-generated with no usage outside the database. If a customer
>wanted their own "external" user IDs, I would likely do something similar
>to the example given, although the user ID would not be the primary key: I
>would make an internal primary key on which the database integrity is
>based. I would also make certain that no user-interaction takes place
>between the assignment of the user ID and the commit, precisely to avoid
>the problem reported.
>
>All that is, of course, just my own opinion, and I know that some will not
>agree. That's ok, I'm delighted to hear their reasoning, because I almost
>always learn something from listening.
>
>Thanks for your comments,
>
>Best regards,
>Dan.

I agree 100% with your approach. I have several applications where the user
either chooses or assigns a number of some kind (a membership number, or a
stock code, or an account number) These have NOTHING to do with the primary
key, which is a unique integer value created by a generator, and which the
user never sees and cannot mess with.

Regards

Tim


[Non-text portions of this message have been removed]