This thread is for discussions of SQL Server Locks.

Please contribute your suggestion in relation with various issues related with log file management in SQL server. Such as
1.    Methods to Shrinking the log file.
2.    Recover the database form Log file
3.    Recovery mode etc

You say (with regard to locking): "For financial code and denormalized aggregates (those little counters of related data that you stash away and try desperately to keep accurate), you should play it safe and not use this technique. But I think you'll find that for better than 90% of your application, it would not be that big of a deal if a user (or even intermediate code) saw an uncommitted modification"

What do you mean? If data is being interrogated, then the returned result set MUST be consistent (ACID).

Seeing uncommitted code is a no-no, whether Financial, denormalized or whatever.

Great.

This little hint with those little word (nolock) saved my life - and the life of our application. (http://www.gpsoverip.de)

Thank you VERY much ...

I've implemented the [WITH (NOLOCK)] hint and it's been a reasonable success.  The only additional note of caution I would add is that we have one table that is occasionally updated (batch inserts).

The problem is that the data is inserted and then the index is updated.  If the index is read after the data has been updated but before the index is updated then this can cause the following error:

Number = -2147217900, Description = Could not continue scan with NOLOCK due to data movement., Source = Microsoft OLE DB Provider for SQL Server, SQLState = 42000, Native Error = 601.