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