Thanks to all replies!

> >Anyway, I think this is an easy way to go wrong and I wonder if a
> >future Firebird version is going to change this?
>
> No, it won't change You are certainly not the first person to have

this

> initial misunderstanding about arguments and replaceable
> parameters. However, once you get used to the way your particular
> interface surfaces the handling of replaceable parameters and SP

arguments,

> I'm sure any problems you perceive will disappear.

Yes, but I think if it is possible to automate this process of
matching it would make working with sp just less error-prone. Imagine
you change a sp you have to find all code places where you set the
parameters even if you only changed the order in the sp. In general I
just dislike the idea of this loose programming-wise connection while
it is strictly requested for running the sp. Maybe I got too much used
to strongly-typed stuff as a .Net developer ;)

> >Beside that I'm deeply impressed by Firebird. I have spent quite

some

> >time with it now and I can't believe how professional this database

is

> >in all meanings and yet for free.
>
> Particularly powerful when you make use of parameterized statements.

A

> number of brain-dead bench tests running Firebird against the

wham-bam

> querying support of certain well-known "competitors" (an in-joke)

throw

> thousands of static SQL statements at the databases, usually
> one-per-transaction, and claim firebird is "slow". The power of

the

> parameterized statement (prepare once, execute often) has not

touched their

> lives yet. :-)
>

Very true! Than I used stored procedures / prepared statements I
really saw this gem shining!

Stefan