One last (well-trodden) comment on the topic.

Rarely is it a good idea to show the user a surrogate key.
Invariably at some point they want to start assigning meaning to it
which goes counter their whole point of being -- to be a meaningless
unchangeable unique identifier. The moment "meaning" is introduced
to the value of a key it becomes a candidate for change.

If a user needs a "unique" identifier with meaning such as invoice
number that encodes year and month plus an incremental number (i.e.
YYYYMM######) then make it a separate column in the table with a
unique index. You'll end up with an unchangeble primary key column
(invoice_id -- created from a generator or other mechanism) and
a "changeable, unique" identifier column (invoice_num). In essence
you will have two unique identifiers for the data. One to manage the
logical relationships between entities in your database and one to
handle user interaction. The advantage is you can change the
invoice_num data (and hence it's meaning) without affecting your
logical relationships between entities in your database.

-Cory


--- In firebird-support@yahoogroups.com, Jonathan Neve
<jonathan@m...> wrote:

> Alan McDonald a écrit :
>
> >>What's wrong with that?
> >>That's exactly what I want. Obviously, it won't be unique before
> >>confirming, and obviously, the code might have to change when

they

> >>confirm the record. That's the idea of confirming. Also, by

confirming,

> >>what I meant was simply inserting the record. So, the value

before

> >>inserting is of no importance.
> >>
> >>Jonathan Neve.
> >>
> >>
> >
> >So why not just show them
> >XXXX
> >as their starter value
> >Alan
> >
> >
> Simply because the generator value is, in practice, almost always

the

> correct value. But as I said, in some cases, I don't show anything

at

> all until the value is confirmed.
>
> Anyway, please could we stop debating this, and get on to the main

topic

> of the thread? This is really a side-issue which I never meant to

bring

> up! :-)
>
> Thanks!
>
> Jonathan Neve.
>
>
> [Non-text portions of this message have been removed]