--- In firebird-support@yahoogroups.com, Kurt Federspiel
<federonline@...> wrote:

>
>
> > --- Adam <s3057043@...> wrote:
> >
> > >
> > > Don't forget to roll back the original INSERT.
> > >
> >
> > Why? If an insert statement raises an exception, it
> > has no effect. Firebird automatically undoes
> > anything it did within the operation if
> > there is an unhandled exception.
> >
> > You only need to rollback if prior operations within
> > your transactions should be considered atomic to
> your
> > insert.
> >
> > Start Transaction T1
> > Insert -> fails with Unique constraint violation
> > Rollback T1
> >
> > has exactly the same effect as:
> >
> > Start Transaction T1
> > Insert -> fails with Unique constraint violation
> > Commit T1
> >
> > Adam
> >
>
> My warning was simply to close the failed transaction,
> which I did not do upon trapping the error.

Yes, you should always use some method of ensuring a transaction is
closed. In Delphi, I usually have something like this:

Tra.StartTransaction;
try
DoWhateverAtomicOperationIsRequired;
Tra.Commit;
except
Tra.RollBack;
raise;
end;

(DoWhateverAtomicOperationIsRequired() may itself react to or ignore
constraint violations depending on the business requirements).

In my

> program, I did neither a commit not a rollback. In
> the Classic Server (WinXP), this created about a dozen
> fb_inet_server processes waiting to timeout.

You are confused between a Connection and a Transaction.

Each fb_inet_server process refers to a *** Connection ***. Each
connection may contain multiple transactions. Ending a transaction
does not close the connection, and so will not affect the number of
fb_inet_server processes you see.

The only think I can think of is if you are using some generic
interface that does not understand the difference between a connection
and transaction that merges them together.

Adam