Subject Re: [IBDI] Re: RowsAffected in SP/Trigger
Author Ann W. Harrison
At 03:28 PM 6/7/2001 +0000, Alexander V.Nevsky wrote:

> Reason of
>my interest to it is: I usually make changes within snapshot
>transactions and have'nt problems - lock conflict solves all of them.
>But now I started to play with read_commited ones. If I make
>Update SomeTable ... Where AttributeCol>Value
>and from previous SP statements I know 1 row should be affected, how
>can I be shure that during SP execution other transaction did'nt add
>and commited one more or changed attribute so my update don't affect
>any? Maybe I'm wrong about read_commited?

I certainly think you are. I'm an old-school database type, having
spent more years than I care to admit trying to provide transaction
consistency. To me, read committed feels like a bulldozer loose in
my flower garden. If you want consistency, asking for read committed
and patching it up afterward reminds me of Lewis Carroll's White

But I was thinking of a plan
To dye one's whiskers green,
And always use so large a fan
That it could not be seen.


We have answers.