Unfortunately I haven't had much time to play with the early Beta of SQL 2005.  However, from what I have seen and heard, the locking will remain largely the same with one addition.  Database views (at least that's the name that was being used when I last heard them discussed) preserve the database as it existed at a given point in time without being a full copy.  Queries against the database view will be satisfied by looking at the "live" data unless the view contains some changes.  This isn't quite the same thing at Oracle's Rollback Segments but it sounds like it might be a good "split the difference" sort of solution.  I will point out again that I haven't actually used this functionality and I don't know the details of what this will mean for transactions and Locking...

I really enjoy All About Transactions - Part 3.I am interested in to hear about your new  article which covers Bound Connections, Distributed Transactions .

Thank you for writing an easy to digest article.

Try BOL......makes my head spin.

Thanks for a great article which clearly explains the balance between isolation and concurrency. I have had to make extensive use of (NOLOCK) in reports to obtain good conurrency because the application I support creates uncommitted transactions every time you open a new form.

I understood from BOL that locking hints were HINTS, and that SQL Server 2000 will ackonwledge them, but will override the hint and select a more suitable level of lock granularity if the operation demands. So selecting WITH (ROWLOCK) when you are updating the majority of rows in a table is likely to be overridden in favour of page or table locks.

David