Without reading all of the past comments, I am going to post what I believe is a valid reason to use NOLOCK.

We have multiple database servers, support one database per customer, approximately 15 customers per SQL Server (2000, 2005, enterprise edition on clustered servers).

We have data that is customer independant, and environment independant, for example system tables with lists of valid file types. Fortunately none of our columns are text, ntext, varbinary, etc... as pointed out earlier as being an issue. (Excellent point however) Basically we have int, varchar, nvarchar, and datetimes. We use views in the customer databases to look at this data.

The reason I feel safe using it ONLY for this customer independant, evnvironment data views is that the data is very static, not very large, and basically used for data integrity.

The reason we implemented the with NOLOCK hint, was that we had hundreds of thousands of connections and locks in CommonData on our production systems which presented a significant overhead.

We attempted making the institution independant data database read-only, but the delays in changing it to/from read only in order to perform maintenance were very significant and could shut down our production customers.

In a general on-line transaction processing database, I would not recommend the NOLOCK hint, but getting static data from a common database, seems safe to me. Just be sure to keep your common database defragmented to prevent the duplicates.

Brian Munier

Brian