At 11:16 PM 12/07/2005 -0700, you wrote:

> >
> > Do you have a field called rdb$db_key in your table mytable?? ie Does
> > this work?
> >
> > select rdb$db_key
> > from mytable
> >
> > Adam
> >
>All tables have this field. It represents the unique row id for a table.

Weeeell, not exactly. Don't bank the ranch on it. Yes, it's unique. But
it's not a persistent value. What it is, is a calculated absolute physical
position of the current version of a row that has been committed in the
past, i.e. newly inserted rows don't have rdb$db_keys. It should always be
regarded as transient, i.e. valid only within the transaction that is
looking at it. In fact, the dbkeys on rows retrieved from joins and views
are seriously complex and quite unpredictable, programmatically speaking.

Unlike M$SQLServer, Firebird's rows don't have a rownumber stored on them
at all (by design). Don't design tables that rely on the dbkey as a unique
key. Do the right thing and design proper relational database tables with
persistent keys.

The default scope of rdb$db_key is the transaction. A connection parameter
can be configured to broaden the scope to the connection, so, to that
extent, it is feasible to make the dbkeys persist for the duration of the
attachment.

Where the dbkey can be really useful is cursor updates inside
SPs. Correctly, it is unnecessary to know what the dbkey is; but the
engine knows it and uses it for ultra fast positioned updates of the WHERE
CURRENT OF <cursorname> style.

There are other ways you can make use of the dbkey, for which you'll need
to translate it into something that you can pass around as a value. See
Claudio's writings on the topic at www.cvalde.net.

./heLen