We use LLBL and SQLServer2005. One of the dba's at the client site has been reviewing traces and sees that our database calls are not using 'with NOLOCK' hints. He is now mandating that we use the NOLOCK hint with all of our queries (both select and update). I see that I can set a property on the DQE for SQLServer to use NOLOCK on selects. My question: is this good practice and are there really benefits to it? Also, is it even possible to use NOLOCK on updates in LLBL? Any thoughts or guidance would be appriciated.

is this good practice and are there really benefits to it

Only if needed, because there are tradeoffs, and yes there are benefits, but also detrements.

In other words, it depends on the database, (size, activity, purpose, and other things).

Is the dba is telling you to do this in order to solve blocking issues?

The point of using NOLOCK is to avoid deadlocks (look at the SQL BOL documentation). I frequently use the NOLOCK situation on selects/fetches. But arschr is right, there are tradeoffs.

The downside of using NOLOCK is that you open up the potential for dirty reads. You can read data that hasn't actually been committed to the database yet and which is subsequently rolled back as part of a failed transaction. i.e. you get bogus data in your selects.

If you don't care about this potential situation, using NOLOCK will help you avoid deadlocks.

Another way of avoiding deadlocks is by doing the reads first, then start a transaction then save and commit. Often people start a transaction and THEN start reading data, and also not by using the same transaction, but by using a new connection which thus blocks.

So if you NEED to read data inside a transaction, be sure to re-use the current transaction for the read. For selfservicing, this means that you first add your entity / collection to the transaction, then call the fetch method(s), and for adapter it means that you use the same adapter as the one you used to create the transaction.