Resolution:  (from a compuserve thread)

The 'connection is in use by another statement' message is due to a limitation within Sybase's DB-Library.  Basically, DB-Library won't allow  you to initiate a new query over a given connection while results are still pending from a previous one.  A DB-Library app that fails to respect  this receives Sybase's infamous 'attempt to initiate query with results pending' message.  You're seeing the Delphi equivalent.

The answer to this is to either ensure that all results are read when a query is initiated, or to open separate physical connections into the  server for each query, as you've done.  Usually, the latter is unnecessary.  To avoid it, just issue a call to the Last method after you open a  TQuery or TStoredProc.  You can then issue a call to First to return to the top of the result set with no adverse effects.  This is usually a  workable solution for small to medium sized result sets.

Thanks for jumping in here.  I do recall having a similar problem with VB and SQL Server, so I looked it up in MS DevNet and found tech  report Q119023 which echoes what you have said.

However, in addition to using Last to flush each query, I'm seeing this problem occur with two executable stored procs (where I can't use  last).  Here's the scenario:

A)  StoredProc1 inserts an audit trail record into a table.  It is called with ExecProc.  ExecProc fails because of an error during insert (a  column defined as not null is null).

B)  StoredProc2 inserts an audit trail into a different table.  It is called after StoredProc1 (whether is fails or not).  When StoredProc2.ExecProc  executes, BAM! "connection is in use by another statement".  When StoredProc1 is successful, StoredProc2 does *not* produce the error.

Forcing a StoredProc1.Close doesn't help, but forcing a StoredProc1.UnPrepare *does* prevent the "connection is in use..." error.