>> This can be JayBird bug too, since prepared statements are cached when
>> you use connection pooling and do not switch it off. In combination with
>> Classic it can produce some funny issues due to metadata cache
>> implementation there.
>
> That sounds like a good analysis. The error message references a table
> by id rather than name:
>
> invalid request BLR at offset 64
> table id 198 is not defined

It seems that it's not. First, I have checked the source code, David uses
physical connections directly - he implemented pooling internally. Therefore
no prepared statement is cached. Second, as you can see from the stack
trace, error happens in isc_dsql_prepare, which cannot be caused by the
outdated BLR in cache.

I will post here my findings as soon as I have something definite.

Roman