At 11:43 AM 22/02/2007, you wrote:

>Thanks for the answer.
>
>Let me get this straight, you are saying that my
>"statement preparation" is being blocked because
>of transaction contention between clients?

No...it was a long-winded way of alerting you to the possibility that
some of the delays would be expected to be due to locking conflicts
if you were using WAIT transactions.

>This hang is happening before the clients actually
>execute the statements. I was under the impression
>that transaction conflicts only happen when the
>statements are actually getting executed.

Actually, at any call after the statement is prepared.

>You mentioned an admin tool, no I dont have one open.
>But my web-based UI could be doing selects while the
>clients are inserting data.

So, is the web application using read-committed transactions?

I have to say that, if all of the observations you reported for your
2-tier users were accurate then the prime source of the delays is in
the remote interface, i.e. time taken between the client's API call
and the server's response to it. This is a black box to Firebird at
both the client and server sides of the interface but the server does
log network errors in firebird.log.

Inside the black box you probably have some routing issues.There was
a thread yesterday that touched on this issue: track through
"FBv1.53 customer moved to Win2003 server = big slowdown". It's not
obvious from the thread's title but you are likely to discover some
elements amongst those postings to get you onto the trail...

./heLen