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
Knight:

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.


Regards,

Ann
www.ibphoenix.com
We have answers.