On Tue, 2005-08-02 at 07:44 +0200, Roman Rokytskyy wrote:

> 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

Have you had a chance to try this against other versions of Firebird? I
suspect that this will not occur with Superserver or Vulcan, but will
probably occur with any of the Classic builds.

To me, this has the feel of an obvious metadata optimization in the OS
process that forms the server side of the classic connection. My
testcase has to create and destroy the same table repeatedly, but it is
not a production case. It is very rare, even for the product I am
constructing, that production tables are created or destroyed. If I am
correct, the Superserver and Vulcan builds will not have this problem
because they do not have to contend with cross-process caching issues.

I may be able to reconfigure my systems this weekend to test my
hypothesis against 1.5.2 Superserver, 2.0, and/or Vulcan.