> Pooling Policy is a good thing but it will only help if someone is
> creating the same report two or more times in a row.
> This is not very likely.

That depends. If that is the same kind of report, it will give you
performance boost. If reports use different SQLs, you will only loose memory
(on the client and on the server).

> Is it right that the only case where statements can be reused after
> closing a connection (giving back to pool) is when the same
> connection is used again and with the same statements ?

Yes. Statement is prepared for the specific connection. If you try to use
the statement (i.e. its handle) in another connection, you will get "bad
request handle" (you've probably seen it).

> It's not possibly to reuse staements with different connection,
> right ?

Right.

> I made the suggustion to keep the statements open, thats right. Is there
> an option to get the old behavior back (only reuse statement as long as
> connection is not given back to pool) ? Maybe thats easy to implement ?

Yes, that should be relatively easy to implement. I will check this and add
another option to the pool.

> Are the statements released ever ?

Statement cannot live longer than connection. In worst case they are
released when connection is closed. In normal case application closes them
right after the use. When statement pooling is used they are not released
until connection is closed. Even more, there is a limit on open statement
handles in Firebird (something ~20,000). Uncontrolled statement pooling
might exaust Firebird.

> Can i do (call) something to release them ?

No, there is no such mechanism and I personally do not plan to introduce it,
unless you come up with a situation where any other approach would not work.
Though I do not mind if you add this mechanism yourself and I will commit
your contribution if it fits the pool architecture.

Roman