Sorry for the long delay in giving a response...

I've just read through all the suggestions and one thing has really
stuck out - why not just go off of the PK... regardless. I need to
shoot that past my supervisor when he gets back from lunch. He was
the one who said don't go off of the PK since it uses a timestamp
that could be reset. Perhaps there is something I'm not considering
in all this.

To clarify a few things from my previous post:
1) We can (and do) insert/delete to/from this database - but using a
legacy program that we don't want to touch (if you were to see the
code, you would know why)
2) On hindsight, posting the same data more than once because of
resetting the date/time probaby should not be the overall issue...
if that happens the reporting tool (part of legacy software) that
uses this database would not show valid data - so we would probably
have to tell user via a pop-up: "you are attempting a date/time
change which will ruin the database reporting results, if you
continue with this operation we will purge the database"

Thanks for all the help!
- Ben


--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:

>
> At 05:32 AM 13/03/2007, you wrote:
> >After lots of looking (perhaps in the wrong the places) I have
> >to post a question that I could not find the answer to. Here is
> >the background info and question: I have a legacy Firebird
> >database that I need to post data from and I cannot manipulate

the

> >database in any way (i.e., I need to work the database "as is").
> >Since my limited database background does not include
> >Interbase/Firebird, I have not been able to figure out how to

pull

> >rows by a rowid (aka - oid, uid, row id, etc.). There are only 5
> >items in the table schema (1 date stamp and 4 ints) and
> >a constraint using an index (as the primary key) that uses
> >the timestamp and lane number (app-specific int value) columns.

I

> >have read about generators, but that there was not one created

for

> >this table. Is there any way to use a rowid (or equivalent) to
> >ensure I don't post the same data twice?
>
> Ann pointed you to the rdb$db_key, but this won't be guaranteed to
> survive past the boundaries of the transaction.
>
> I'm curious to know what your thinking is about using some *other*
> unique value to "ensure I don't post the same data twice". The PK

is

> (by nature) unique so WHERE LANE_NUMBER = ? AND THETIMESTAMP = ?

is

> enough to ensure that you find the unique value for an update or
> delete, and to cause a PK violation if you try to post the same
> combination twice.
>
> Surrogate PK identifiers, such as a Row ID or a generated unique
> number, or indeed the rdb$db_key, make it easier to find things

for

> positioned updates, but they don't make any difference to the

quality

> of "uniqueness" in the compound key. A key is either unique or it

is not.

>
> ./heLen
>