> > I think it would be VERY useful to have a trigger/stored procedure
> > language enhancement such that you could do something like this:
>
> > UPDATE ATBL
> > SET ACOL = :VAL
> > WHERE AKEY = :KEY
> > AFFECTED :ROWS_AFFECTED;
>
> It was in my wishlist, and I think it will be enough to have system

variable

> for connection (transaction?) context, just to be ensured that last UPDATE

or DELETE

> statements inside procedure or trigger will populate ROWS_AFFECTED.
>
> People wants to know is there were any records updated or deleted by last

statement, or not.

> This feature is already available in IB API, and used in BDE and other

client libraries.

Architecturally this is going to be very different. With the API you have a
distinct statement handle which provides the information. In this case you
are inside the granular operations being carried out by a statement.

I am quite certain this is more of a language extension than mapping it
through existing client mechanisms on the server-side.

The way I am promoting it to be implemented could very cleanly be
accomplished by enhancing the underlying BLR of the statement and taking the
result of the looped iterations and returning it to the AFFECTED return
variable. To tell it to go through an API using connection or transaction
handle (neither of which delivers rows affected anyway) smacks as overkill
for the job. This also implies there are some buffers somewhere which
monitor each granular operation of a stored procedure and there isn't such a
thing, nor should there be, IMHO.

Also, it is a key distinction that the mechanism isn't wanting to know
exactly what physical updates, inserts or deletes are carried out but if the
UPDATE where clause was "on-target" for the row or rows I wanted operated
upon. Using an internal BLR loop counter is a cheap and easy way to return
this meaningful piece of information.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com