>> This is triggered by an IOException as well, unfortunately I didn't
>> include it for this Exception. However, this IOException should be
>> logged if you have logging setup and enabled on debug level.
>>
>> The stacktrace you sent earlier was with iscStartTransaction as well,
>> but then during the send of the transaction start operation, now it is
>> failing after the operation has been sent, but during the receive of the
>> response from the server. Is there anything in the logs of Firebird?
>>
>> I will review the transaction code. Do you by any chance use a custom
>> transaction parameter buffer or transaction configuration?
>>
>> Mark
>> --
>> Mark Rotteveel
>>
> I'm just using plain DataExpress components without any transaction. And these Exceptions occurs on read operations.
>
> And seems that default transactionisolation is READ_COMMITED. Do you think its a good idea to experiment with this parameter?

Can it be that you use a connection pool and the connection was
"waiting" in the pool for a long time, then it is accessed and the first
network operation fails?

In old pool classes there was a property which caused the pool to
execute some statements that should always work (SELECT 1 FROM
rdb$database), and if it failed, it recycled the connection before it
was returned to the application.

Roman