> In the prepare step, roughly explained, the engine parses the SQL text,
> checks the syntax and compiles it into a Firebird native executable form
> (BLR).

Yes this what i understand too, and this why 50 ms seem huge ...

> My guess is that you are assigning the SQL text over and over again,
> which leads to re-preparing the statement everytime the SQL statement is
> executed.

but in the test, i simply do
isql connect;
isql select ...
isql commit;

and here i see 50 ms :(

> Optimize your application in a way to keep the most important
> or most frequently used statements prepared for later reuse. Every tried
> to insert e.g. 100000 records in a loop with and without a prepared
> statement?

yes, when i do bulk insert, i alway do with parametized query (and believe it's terrific more faster than without in some case), but for select is not always so evident because i can not keep the prepared statement open (but i will study it to be sure)

EX: user 1 come and say i want info of obj 1
few time after user 2 come and say i want the info of obj 98

i still don't know how to keep the statement prepared between these 2 query done by 2 different users... but i will investigate

> But, do we drift away from your original problem, where a single
> execution of your statement on different tables (with/without a longish
> VARCHAR field) with the same number of records was a magnitude slower?

yes the original probleme is why in a single execution, the prepare is so much huge with long varchar in the table (not in the select). that still the problem