Subject | Re: [IBO] TIBOQuery EditSQL with an anonymous sql block |
---|---|
Author | Helen Borrie |
Post date | 2003-10-24T05:11:46Z |
At 01:48 AM 24/10/2003 -0300, you wrote:
EditSQL property itself isn't a statement object, so it doesn't surface any
column objects of its own. IBO passes the input values to it internally
from the statement object that owns it.
If you wanted to access the column objects of a call to a stored procedure,
you would need to create a statement object for it. Then you will be
looking at a different (less convenient, unncecessary) arrangement of your
task's workflow. Stick with the "updatable dataset" model you are using
now. You have no need to go to such lengths and create "bubbles" in task
sequence.
module source. PSQL features can't be used in DSQL (which is what you use
in IBO and other API interfaces).
GeneratorLinks uses it.)
So place the function call on the connection object, like so:
with YourIBOQuery do
begin
if FieldByName('ItemID').IsNull then
FieldByName('ItemID') := IB_Connection.Gen_ID('TheGeneratorName', 1);
inherited;
end;
Helen
>Hello Hellen,I think you are misunderstanding how the statement object works. The
>
>At 12:13 AM 24/10/2003 -0300, you wrote:
> >>EXECUTE PROCEDURE ITEM_ORDER_UPDATE(
> >> :ItemId, :ProductId, :Value, :OrderId
> >> , :ItemId /* return a value */
> >>)
> >
> >You're getting the error actually because you have included the output
> >parameter in the input parameter list. You don't do that. Execute
> >Procedure takes only only input arguments. IBO sets *itself *up for the
> >output parameters when it calls and processes Prepare().
>
>Does the output parameter have to have the same name of the dataset's field
>(suposing I modify some fields at server side)?
EditSQL property itself isn't a statement object, so it doesn't surface any
column objects of its own. IBO passes the input values to it internally
from the statement object that owns it.
If you wanted to access the column objects of a call to a stored procedure,
you would need to create a statement object for it. Then you will be
looking at a different (less convenient, unncecessary) arrangement of your
task's workflow. Stick with the "updatable dataset" model you are using
now. You have no need to go to such lengths and create "bubbles" in task
sequence.
>I supose you cannot use the returning_values clause at EditSQL,No, that is PSQL - the subset of SQL that is confined entirely to server
>InsertSQL,,,,etc ?
module source. PSQL features can't be used in DSQL (which is what you use
in IBO and other API interfaces).
>OK. I followed your advice and I had to change the identifier generation toIt *might not* be surfaced as a method to TIBOQuery (although
>the client side, and put at server side only the insert/update sql
>sentences. Everything is fine know :)
>
>Where's gen_id function? I had to use a 'select gen_id(x,y) from
>rdb$database' (dual).
GeneratorLinks uses it.)
So place the function call on the connection object, like so:
with YourIBOQuery do
begin
if FieldByName('ItemID').IsNull then
FieldByName('ItemID') := IB_Connection.Gen_ID('TheGeneratorName', 1);
inherited;
end;
Helen