At 01:46 PM 11/07/2003 -0300, you wrote:

>Ok it´s other problem ( and now we have a soluction - maybe not usefull
>because other developers, like a governament, can use this flag turned off)
>:-((

We all build perfect systems and we all know how users can find ways to
break them!!

>with the other trouble, I can talk only the following:
>
>When I do a select with a sub-select (having more parameters than the master
>select) using Date and ShortInt parameters, the parser in some times result
>two ou three parameters with same name and different types, for example:
>CodEmpresa as Date and CodEmpresa as Integer!
>
>Of coarse, the error message '14' is not a valid date, is a Delphi Message,
>but it´s occur inside the IBO code.

Yes, you are right, this is a client-side problem. What you are trying to
do is "recycle" parameters so that the same actual parameters are re-used
for DIFFERENT parameters in your query. You need to understand the
difference between a parameter OBJECT and a parameter VALUE. You need one
parameter OBJECT for each parameter - even though you know that many of
these parameter objects will always have the same VALUES at runtime.

To get you thinking about what you have to do, here is part of your query
string, with the proper usage of parameters (no recycling!!)

Select Count(Distinct X.NumLote) as Total,
(Select Count(distinct A.NumLote) from Co_Lct A Where
A.CodEmpresa=:CodEmpresaA and A.Identificacao starting with 'LA' and A.Data
between :DataInicialA and :DataFinalA) as TotLA,
(Select Count(distinct B.NumLote) from Co_Lct B Where
B.CodEmpresa=:CodEmpresaB and B.Identificacao starting with 'RA' and B.Data
between :DataInicialB and :DataFinalB) as TotRa,
(Select Count(distinct C.NumLote) from Co_Lct C Where
C.CodEmpresa=:CodEmpresaC and C.Identificacao starting with 'CA' and C.Data
between :DataInicialC and :DataFinalC) as TotCa,

...and so on

To ensure that each subquery gets the correct parameter VALUE, it must have
its own parameter OBJECT for each required substitution. Your parameter
assignments are getting scrambled because you are trying to re-use the same
parameter objects for parameters which have to be passed to the XSQLDA
structure as separate parameters.

There was discussion recently in this list where it was proposed that
"parameter recycling" might be implemented for situations like yours, i.e.
have the IBO parser identify cases where parameter re-use is wrongly
requested, and reconstruct the query specification internally to correct it
before passing it to the API. I looked through the release notes up to the
current test patch but I cannot see any note saying that it has been
implemented yet...

I'll leave it up to Jason to explain the status of things currently.

Helen