Grigore,

now I see your problem better ... this explanation was missing.

How is your Update where clause set in the view? I assume the setting is "primary key only". If you set it "primary key and modified fields, the update will cause an update conflict error, you can then requery the view and your user is presented the current stock and he will see, that he can't get that many items out of the stock.

HTH,
Armin


>Michael,
>
>Thank you so much for the answer. Let me expose the problem, then:
>
>I have a specific app, with a very senzitive table: the stock table. I need a way to be sure never ever stock goes negative. More specifically, I need a way to avoid the following:
>
>Suppose stock is 100.
>User A selects the rows, and he want to take 70 from those 100.
>User B selects the rows, and he want to take 60 from those 100. He can read the 100 value, because the transaction allow him to read the rows, even they are locked.
>user A updates the table
>user B updates the table
>
>The result: from 100 maximum, they got 130.
>
>How to avoid this?
>
>I'm sorry I'm pushy, but I am very close to lose a contract because of that....
>
>Thank you so much.
>
>>I'm not sure what you saw in the past. Starting a SQL Server transaction does not "protect the data." Locks protect the data and the presence or absence of a transaction determines the length of time that the locks are held.
>>
>>You should be able to see this. Start the transaction and modify a row w/o commiting the transaction. If you try to modify the same row on a different connection, SQL Server will block the modification until the first transaction is terminated - causing the lock to be removed.
>>