| Subject | RE: [IBO]Parameter values in DeleteSQL |
|---|---|
| Author | Helen Borrie |
| Post date | 2006-06-15T17:13:12Z |
At 01:20 AM 16/06/2006, you wrote:
parameters don't have names.
IBO is an interface between Delphi and the API. The API is a very
formalised structure of stuff. The part that transports parameters
back and forth has to be constructed by IBO to comply with this
structure. Its all in positions and numbers. So IBO first creates a
structure called the XSQLDA which tells it how many input parameters
and output parameters to look out for. So then the XSQLDA will be
looking for a bunch of structures in order, each containing positions
that will be filled with information about type, size, etc. These
are called XSQLVARs. The order is determined by the order in which
the parameters are listed in the statement.
In between, IBO applies the convention of giving names to each
parameter. That's what *we* use in our application code. IBO takes
care to ensure that the names of the parameters match up with the
order. Note also that we can refer to them by order as well, if we
want to, because IBO stores them in an ordered list called
Params. The only catch is that we use Delphi array notation
(zero-based arrays), whereas the XSQLDA deals with the XSQLVARs in
1-based order. But IBO takes care of that, too, so we don't have to.
NOT variables in the API.
Actually, I'm pretty tired of the whole discussion. Feel free to
carry on, but don't feel obliged to respond to this. I think I've
said about all I have to say on the subject --- several times over in
one way or the other.
Helen
>My point is that it shouldn't be different.But you're wrong, i.e. it's not a question of your opinion.
>I'm guessing now . .Wrong, quite wrong. As I think I already explained, in the API,
>I assume IBO gets a list of parameters from the API which includes their
>names.
parameters don't have names.
IBO is an interface between Delphi and the API. The API is a very
formalised structure of stuff. The part that transports parameters
back and forth has to be constructed by IBO to comply with this
structure. Its all in positions and numbers. So IBO first creates a
structure called the XSQLDA which tells it how many input parameters
and output parameters to look out for. So then the XSQLDA will be
looking for a bunch of structures in order, each containing positions
that will be filled with information about type, size, etc. These
are called XSQLVARs. The order is determined by the order in which
the parameters are listed in the statement.
In between, IBO applies the convention of giving names to each
parameter. That's what *we* use in our application code. IBO takes
care to ensure that the names of the parameters match up with the
order. Note also that we can refer to them by order as well, if we
want to, because IBO stores them in an ordered list called
Params. The only catch is that we use Delphi array notation
(zero-based arrays), whereas the XSQLDA deals with the XSQLVARs in
1-based order. But IBO takes care of that, too, so we don't have to.
>It then presumably creates a structure for returning these with values.One XSQLVAR refers to one parameter. Again, I stress, that these are
>When it processes a param assignment I assume it gives up after the first
>occurrence of the param name ignoring any duplicates?
NOT variables in the API.
>If this assumption is correct I would have thought it would be a greatNot for me. I want the interface to reflect the API.
>improvement to get it to process any additional parameters with the same
>name.
>It also messes with the values turning '' into ' ' for a char(3). II'm too tired to process this.
>wonder what the justification for this is as FB seems happy to compare a
>char(3) with ''?
Actually, I'm pretty tired of the whole discussion. Feel free to
carry on, but don't feel obliged to respond to this. I think I've
said about all I have to say on the subject --- several times over in
one way or the other.
Helen