Get Entity Framework 6 use NOLOCK in its underneath SELECT statements

First of all... You should NEVER EVER use NOLOCK for each and every SQL Statement. It could compromise the integrity of your data.

It’s like any other query hint a mechanism you should only use when you do something out of the ordinary.

There is no way to tell the EF Provider to render the NoLock hint. If you really need to read uncommitted data you have the following option.

1. Write your own EntityFramework Provider.

2. Use a Command Interceptor to modify the statement before it is executed. http://msdn.microsoft.com/en-us/data/dn469464.aspx

3. Use a TransactionScope with IsolationLevel.ReadUncommited.

I know you said you do not want to use Transactions but it's the only out-of-the box way to read uncommitted data. Also it does not produce much overhead as each statement in SQL Server “implicitly” runs in a transaction.

using (new TransactionScope(
                    TransactionScopeOption.Required, 
                    new TransactionOptions 
                    { 
                         IsolationLevel = IsolationLevel.ReadUncommitted 
                    })) 
{
        using (var db = new MyDbContext()) { 
            // query
        }
}

EDIT: It's important to note also that NOLOCK for Updates and Deletes (selects remain intact) has been Deprecated by Microsoft as of SQL Server 2016 and and will be removed in 'a' future release.

https://docs.microsoft.com/en-us/sql/database-engine/deprecated-database-engine-features-in-sql-server-2016?view=sql-server-2017

You can use a workaround that don't use transaction scopes for each query. If you run the code below, ef will use the same transaction isolation level for the same Server Process ID. Since Server Process ID does not change in same request, only one call for each request is sufficient. This also works in EF Core.

this.Database.ExecuteSqlCommand("SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;");

I agree with what codeworx says in a way that Read Uncommitted can be dangerous. If you can live with dirty reads, go for it.

I found a way to make this work without changing anything in the current queries.

You need to create a DbCommandInterceptor like this:

public class IsolationLevelInterceptor : DbCommandInterceptor
{
    private IsolationLevel _isolationLevel;

    public IsolationLevelInterceptor(IsolationLevel level)
    {
        _isolationLevel = level;
    }



    //[ThreadStatic]
    //private DbCommand _command;


    public override void ReaderExecuting(DbCommand command, DbCommandInterceptionContext<DbDataReader> interceptionContext)
    {
        SetTransaction(command);

    }

    public override void ScalarExecuting(DbCommand command, DbCommandInterceptionContext<object> interceptionContext)
    {
        SetTransaction(command);
    }

    public override void NonQueryExecuting(DbCommand command, DbCommandInterceptionContext<int> interceptionContext)
    {
        SetTransaction(command);
    }




    private void SetTransaction(DbCommand command)
    {
        if (command != null)
        {
            if (command.Transaction == null)
            {
                var t = command.Connection.BeginTransaction(_isolationLevel);
                command.Transaction = t;
                //_command = command;
            }
        }
    }

}

then at the cctor (static contructor of your dbcontext) just add the interceptor to the DbInfrastructure of entity framework collections.

DbInterception.Add(new IsolationLevelInterceptor());

this will for each command that EF sends to the store, wraps over a transaction with that Isolation Level.

In my case worked well, since we write data through an API where that data is not based on the readings from the database. (data can be corrupted because of the dirty reads) and so worked fine.