Subject | Re: [Firebird-Architect] Exec. statement parameters |
---|---|
Author | Alex Peshkov |
Post date | 2007-12-11T08:04:53Z |
On Tuesday 11 December 2007 03:17, Adriano dos Santos Fernandes wrote:
example. One write SQL request in Delphi:
select :param, p.* from Proc(:param) p
and gets very surprised, why database server does not understand what is a
type of param. Why it understands 'select * from Proc(:param)' but not an
original operator. It takes time for people to understand that actually
select ?, p.* from Proc(?) p
was written, and this 2 '?' are not related from server's POV. And use of
named parameters in DSQL API solves such problems.
> Unnamed parameters is easier to write. Thanks to TYPE OF COLUMN, currentIn some other cases when named parameters are very useful. Old well known
> EXECUTE BLOCK syntax may be less tedious, as one doesn't need to know
> columns types to replicate in the parameters type.
>
> And unnamed parameters may also look like named ones, if you put it
> after variable declaration.
example. One write SQL request in Delphi:
select :param, p.* from Proc(:param) p
and gets very surprised, why database server does not understand what is a
type of param. Why it understands 'select * from Proc(:param)' but not an
original operator. It takes time for people to understand that actually
select ?, p.* from Proc(?) p
was written, and this 2 '?' are not related from server's POV. And use of
named parameters in DSQL API solves such problems.