Thanks Geoff,

> > Should I set up a Transaction Component as well?
>
> Yes. The default transaction is there for to make it simpler for
> simple applications, but should not be relied on for more advanced
> purposes. IMO it is always best to be explicit.
>

Amazing what you learn through tough problems, I see the OAT etc advancing
as records are added, so I believe from this that the transaction is closing
OK.

> It is a curious problem that you are getting, I wonder if your
> application is holding a transaction open for all that time? (Another
> reason for using your own transaction so you can explicitly commit it
> when finished a section of work.)

So the correct plan of attack would be:

Prepare; (If not prepared)
Execute;
Commit;

> Could it be that your connection is dropping for some reason? Perhaps
> the server has been restarted (check the interbase.log file in the
> ib/fb installation directory).

I don't believe this to be the case. The connection is through localhost,
and other DSQL components over the same connection continue to execute
correctly. Just one of them fails and stays failed, until the process is
restarted. (I must admit my error handling is thin).

If the DSQL component or Transaction were screwing up, what would be the
best way to recover? Would Disconnect/Reconnect clean it up?

> Jason has a base service application available that may offer you some
> help.

I looked into this, but it is overly sopistocated for my application since
the inserts are handled via the receive method of a comms component, his
component did not appear conducive to this structure (IMO anyway). The
Logging etc is nice though :))

John