--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> 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.

Understood, how IBO works. Let me explain why I wanted to change
argument value: SSP returns row if related ID is not found another
table. So, insert and delete operations are reversed - if wanted to
insert new record - I need to delete row from related table; if wanted
to delete - then to insert row to the related table.
Delete operation works ok, but then I want to insert new row, I need
to pass other SoID to EXECUTE DELETE statement than is returned from
the SSP. Such solution is efficent to store one table's row subset,
when difference is only 1-3 rows.
So I needed manually change argument value for EXECUTE DELETE
statement. And then problems started to appear :) If have any
suggestions, let me know

> End of story, end of song. All is done. Repeat, do *not* try to

assign

> these yourself.

Aleluja, Helen, the light of truth is shown to me ;) end of story, end
of song - thanks