At 03:27 PM 12/3/2001 +0300, Dmitry Kuzmenko wrote:

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

The number of records affected is a statement property, not a transaction,
connection,
user, or database property. A database can have many users, a user many
connections,
a connection many transactions, and a transaction many simultaneously
active requests.
(Kits, cats, sacks, wives, how many were going to Saint Ives?)

Jason's original request could be satisfied if the procedure did a FOR SELECT
loop to drive the updates with no change to the current architecture, but
that leaves open the original question: What problems are solved by knowing
the number of rows affected?


Regards,

Ann
www.ibphoenix.com
We have answers.