Hi Luc,

> seems my answer is lost somewhere in cyberspace....

Nope, got your other one, thanks - might have taken a while though!

> > INSERT INTO table1 (col2, col3) VALUES (col2Val, col3Val)
> >
> > and the call returns the id of the newly created row.
> >
> > Is one possiblity locking the table for writing? That would mean
> > the trigger couldn't get called before I call the
> >
> > SELECT GEN_ID(GEN_ATABLE, 0) FROM RDB$DATABASE;
>
> use:
> SELECT GEN_ID(GEN_ATABLE, 1) FROM RDB$DATABASE;
>
> to get the next generator value.
> That's safe (since it's equivalent to GEN_ID ( GEN_ATABLE, 1 ) in a
> trigger)

Just wanted to clarify - I'm thinking of creating a transaction that
locks the table for writing, issues the same insert statement that
the programmer passed in (as above) and therefore calls the trigger
to add the id - IF (NEW.ID IS NULL) THEN NEW.ID = GEN_ID
(GEN_ACCOUNTS_ID, 1).

Now, if in the SAME transaction with the table still locked, I call
SELECT GEN_ID(GEN_ATABLE, 0) FROM RDB$DATABASE; to get the id of the
row just inserted, will this be safe?

This way, I can preserve all the insert calls that already exist,
use a trigger to insert the id, and then make the call to be able to
return the id. I realise I can do it the other way - get the id
before I add the row and add it to the insert statement - but this
will be a heck of a lot easier in terms of the current code base!

What do you think?

Thanks again,

David