Whoaa .. hold on !! :)

Let me make sure I understood your scenario first ---

Your web page reads data, including timestamp, then you disconnect from the
db, the user takes 2 seconds - 2 weeks, and then you update modifications
back into the db, and there is where you check for timestamp (during
update).

I think, for this scenario, the more appropriate isolation level will be
ReadCommitted, not RepeatableRead.

Why?

If you have a transaction block thta looks like this

BEGIN TRAN
Select
Update
COMMIT

.. Then yes, you would want RepetableRead, because between the Select and
Update, you want to ensure repetable reads - thus ensuring that any other
transaction doesn't screw up what you read out of the Select statement ..
right?

BUT ..

really your transaction block looks like this ..

BEGIN TRAN
 Update
COMMIT

The Update Query itself has a where clause, and SQL Server guarantees data
consistency over the lifetime of the query execution, so a simple Update
Query, with the timestamp in the where clause .. under ReadCommitted, should
do the trick :).

Of course the next Q is, "What if two updates are issued together"?

Well, even then, SQL Server will automatically serialize them in an
execution order - they never execute together.

So, my vote is for ReadCommitted - lower cost, same effect. What am I
missing heya?

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------