>You should have the insert of a master and its detail records within the
>context of a single unit of work. You can use the default transaction or an
>explicit one that you use for this. Keep in mind a TIBODatabase will default
>to AutoCommit as true and a TIB_Transaction will default to AutoCommit as
>false.

Does AutoCommit mean that each insert is committed immediately after
execution? Is that a bad thing in my situation?

Is the purpose of transactions basically to control when commits are done,
or is there more to it than that?

I'm a little confused about how commits and transactions interact with key
violations. In my situation, the client queries the database to find out
what the last key used was. It then increases that number by one and
inserts a record with that key. Let's say two users are doing this
simultaneously. They may both query at the same time and try to store
records with the same key. Now, if Client A inserts first, but doesn't
commit yet, then Client B inserts, will Client B get an immediate key
violation? If not, then does the first one to commit succeed, and the
other get a key violation? Or, does Client A get preference for having
inserted first? I guess I'm basically asking two questions: 1) Does the
insert reserve the key, or does the commit reserve it? 2) Does in insert
trigger a key violation, or does the commit trigger it?

Here's my concern: After inserting the master record, the app needs to
insert several detail records, including the master's key for later
reference. If there's going to be a key conflict on the master records, I
want to know that BEFORE I start inserting detail records. Otherwise, the
detail records could get linked to the wrong master record, causing a nasty
mess to clean up if the master record insert fails. Does that mean that I
should commit the master record before inserting the detail records? If
so, wouldn't that be a reason to make it two transactions instead of one?

-Joe