Re: [Firebird-devel] Incorrect mapping of SQLDA parameters

[Jason W. <jwh...@ib...>]

What I would really appreciate is at the same time if you made it so that
input parameters could pass in a name and that this name would appear in the
SQLVAR record when doing the prepare/describe. It would also be great if you
could define a SQLType for a parameter in the statement and have this be
taken into consideration rather than an exception raised.

While you are in the parameters thing, just as well tidy up all the issues
so that there is a simple check in code for all the new features that are
needed.

Reason I ask for the handling of names for input parameters is because then
I wouldn't have to care much what order the input parameters are in. The
server would tell me their names and they could be in any order it wanted.

Also, let me give you a beware, when you have a column of a query defined
using an inline select that has an input parameter and then in the order by
clause you refer to that column by number the input parameter of the inline
select gets repeated automatically. Ideally it would be nice if you
consolidated that to reuse instead of duplicating.

Thanks,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

-- We may not have it all together --
-- But together we have it all --


"Nickolay Samofatov" <sk...@bs...> wrote in message
news:932...@bs......
> Hello, All !
>
> I'm fixing bugs in SQLDA parameter mapping. I even fixed them in fact.
> For those who don't remember, current order of SQLDA parameter in
> select statements and subqueries is:
> FROM-CLAUSE, FIRST-CLAUSE, SKIP-CLAUSE, WHERE-CLAUSE, GROUP_BY-CLAUSE,
> SELECT-LIST, ORDER_BY-CLAUSE, HAVING-CLAUSE
> Redundant parameters are generated for fields in ORDER_BY-CLAUSE and
> GROUP_BY-CLAUSE accessed by index (but not in order_by-clause of union).
>
> I.e. number and order of parameters doesn't match SQL source string
> which order is:
> FIRST-CLAUSE, SKIP-CLAUSE, SELECT-LIST, FROM-CLAUSE, WHERE-CLAUSE,
> GROUP_BY-CLAUSE, HAVING-CLAUSE, ORDER_BY-CLAUSE.
>
> This inconsistency makes usage of parameters really painful experience.
>
> There are tools that rely on this incorrect behavior while generating
> dynamic SQL. It seems that popular ones like IBExpert are among of
> them.
>
> Supporting both new and older behavior is difficult and ill-formed,
> but usage of new semantics will break compatibility with some of
> existing applications.
>
> What I'm going to do is to test my fix some more and commit it to CVS
> as is. Suggestions ?
>
> --
> Best regards,
>  Nickolay Samofatov                      mailto:sk...@bs...