| Subject | Re: [IBO] mystery with ParamByName |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-11-17T12:56:58Z |
At 12:06 PM 17/11/2004 +0000, you wrote:
arguments of a BOUND dml statement*. To repeat, IBO takes care of these
interfnally.
TUID is "known" to the dataset as a param - but it is the param of the
SELECT statement. DO NOT ASSIGN IT TO THE BOUND DML STATEMENT.
Can we please get clear finally about this:
1. Your DATASET is drawn from a selectable stored procedure. It has a
Param (TuID). Because the SSP has an output set, the output (i.e. RETURNS
list) is treated by IBO as Fields[].
OK, next, you define a DeleteSQL for this set (because this is the only way
to make these virtual rows behave like a live dataset).
This DeleteSQL is an executable statement - it might be a DELETE statement
but, as it happens, it is an EXECUTE PROCEDURE statement:
execute procedure del_blah (:TuID, SoID)
Right, now you gave this statement "parameters", which (because it is a
stored procedure call) are the input arguments for the stored procedure.
The DeleteSQL is *bound* to the dataset. It has no params that you can
access from code. Instead, IBO takes care of it. How it binds the
DeleteSQL to the dataset is by way of the argument parameters that you
supplied in your EXECUTE PROCEDURE statement.. This works as long as the
*names of the argument parameters* match field names in the dataset.
When you call Delete(), IBO binds the values of the fields TuID and SoID to
the DeleteSQL statement's argument parameters :TuID and and :SoID,
respectively.
End of story, end of song. All is done. Repeat, do *not* try to assign
these yourself.
Helen
> > > OK, there are two problems with this procedure. 1) it needs togood. :-)
>have
> > TUID
> > > in its output set
>
>Helen, added TuID to output set,
>but still can't assing SoID argumentAs I explained in the previous message, *do not assign values to the input
>with the ParamByName - field not found. TuID field as argument is
>found.
arguments of a BOUND dml statement*. To repeat, IBO takes care of these
interfnally.
TUID is "known" to the dataset as a param - but it is the param of the
SELECT statement. DO NOT ASSIGN IT TO THE BOUND DML STATEMENT.
>Am I right, that IBO SP argument (AFields) list is independent fromI don't understand what you are trying to say here, because it makes no sense.
>the output set (Fields) list? when argument list is created, destroyed
>and cleared?
Can we please get clear finally about this:
1. Your DATASET is drawn from a selectable stored procedure. It has a
Param (TuID). Because the SSP has an output set, the output (i.e. RETURNS
list) is treated by IBO as Fields[].
OK, next, you define a DeleteSQL for this set (because this is the only way
to make these virtual rows behave like a live dataset).
This DeleteSQL is an executable statement - it might be a DELETE statement
but, as it happens, it is an EXECUTE PROCEDURE statement:
execute procedure del_blah (:TuID, SoID)
Right, now you gave this statement "parameters", which (because it is a
stored procedure call) are the input arguments for the stored procedure.
The DeleteSQL is *bound* to the dataset. It has no params that you can
access from code. Instead, IBO takes care of it. How it binds the
DeleteSQL to the dataset is by way of the argument parameters that you
supplied in your EXECUTE PROCEDURE statement.. This works as long as the
*names of the argument parameters* match field names in the dataset.
When you call Delete(), IBO binds the values of the fields TuID and SoID to
the DeleteSQL statement's argument parameters :TuID and and :SoID,
respectively.
End of story, end of song. All is done. Repeat, do *not* try to assign
these yourself.
Helen
>