> You may be right Adam, the problem may very well come from the
> transaction component instead of the database component itself.
> However, I am not sure if it is a good idea to nullify any component
> that has not yet been freed for fear to create an access violation
> when its owner tries to free it at a later time.
>

A couple of things to get straight. If you create these components at
design time rather than run time.

The owner of the database component is the form / datamodule
The owner of the transaction component is the form / datamodule

You can check this by doing something like

showmessage(TObject(con.Owner).ClassName)
showmessage(TObject(tran.Owner).ClassName)

etc

The connection component probably has a default transaction property.
The transaction component probably has a default connection property.

I am not suggesting you nullify con or trans here, but rather after
explicitly committing or rollback of the transaction(s), and
explicitly closing the connection, set

con.DefaultTransaction := null;
tran.DefaultConnection := null;

This does not free the object, but rather means when you do free the
object (which will happen when you free the owner form or datamodule),
the component will not attempt to access the other component, which
was obviously already freed.

> I tried to explicitely free the database and transaction components
> in various orders without success (i.e. I get some access violations
> each time).
>
> For the time being, I think I will stick with Terry's suggestion to
> use ExitProcess(0) instead of Application.Terminate, which seems to
> very well address the problem to a certain degree.

It doesn't really address the problem, it just aborts it. I imagine
that the OS will eventually take care of the memory space, but you may
retain other handles and open files for a lot longer.

Adam