>I guess by now you realise that that isn't going to protect your data
>integrity at all well and could leave you with either unwanted master
>records or orphan detail records.
>
>Please get rid of your transaction-dependent manufactured keys and use
>Fb/IB as it was designed to be used.

Thanks for all the info. I've known about generators, but haven't
implemented them so far, since it seems like a lot of work to make the
conversion. I try not to do metadata changes more than once per year. I
didn't set it up that way originally because my app originally used
Paradox, not IB, and most of the code was reused.

For now, what I've been doing has worked very well. As long as I commit
the master record, I know whether I got a unique key or not. If I get a
Key Violation, I bump it up one more and try again until I succeed. (A key
violation actually rarely happens, since there are generally only 2-3 users
at a time, and the chances of them grabbing a key at the same instant is
slim.) Once it succeeds, I know what the correct master key is, and can
insert my detail records safely. I'll continue this way for now. Your
other answers gave me the answers I needed to proceed in moving to TIB_DSQL
objects and explicit transactions.

Maybe next year I'll look into implementing generators. If I do that, will
all my original keys still be valid, or do I have to re-pump the
data? When I create the generator, will it automatically know where the
keys left off last time?

Actually, one other reason I can think of to avoid generators is possible
gaps in numbering sequences. Let's say I insert a record, but then end up
rolling it back. Isn't it's key number gone forever? You said that once
it's generated, it will never be re-used. That would leave a gap in the
numbering sequence. My customers don't like to see that. They want the
sale numbers to be continuous without gaps. Otherwise it looks like
someone may have been tampering with the data.

-Joe