0

Ich habe eine gespeicherte Prozedur zum Archivieren einiger Tabellen. Es läuft ~ 30 Minuten (erster Lauf, bewegt mehr als 20 Millionen Datensätze). Wenn ich das Skript von Management Studio aus starte, kann ich andere Abfragen und alles, einschließlich der zu archivierenden Tabellen, ausführen.Sperre läuft von EF und nicht von Management Studio?

Wenn ich jedoch das Skript aus dem Code (C#, EF) ausführen, kann ich keine Ergebnisse vom Server erhalten, nicht einmal von Management Studio. Ich denke (hoffe), das muss ein paar Verbindungsstring Tweak sein, aber ich weiß nicht, wonach ich suche. Was ist der Unterschied zwischen mmstudio und ef ExecuteSqlCommand?

C# Code, der die gespeicherte Prozedur ausgeführt:

SqlParameter daysparam = new SqlParameter("@Day", days); 
using (ReportsContext rcx = new ReportsContext()) 
    { 
     rcx.Database.CommandTimeout = 60 * 40; 
     rcx.Database.ExecuteSqlCommand("Archive @Day", daysparam); 
    } 

Die Verbindungszeichenfolge:

connectionString="data source=localhost\SQLSERVER2014;initial catalog=****_dev;persist security info=True;user id=sa;password=***;MultipleActiveResultSets=True;App=EntityFramework" 
+0

Es hängt von Ihrer Transaktionsisolationsstufe ab, versuchen Sie, die EF-Isolationsstufe in Snap zu ändern Schuss oder readuncommited –

+0

Ja, ich habe vergessen, dass die sp mit 'SET TRANSACTION ISOLATION LEVEL UNCOMMITTED beginnt zu erwähnen LESEN;' ' SET DEADLOCK_PRIORITY LOW;' Btw, das gleiche sp läuft ohne Problem vom Management Studio. – Perrier

+0

versuchen, TransactionScope vor dem Kontext zu verwenden und es zu testen –

Antwort

1

Die Lösung TransactionalBehavior.DoNotEnsureTransaction als ersten Parameter des ExecuteSqlCommand hinzuzufügen war:

rcx.Database.ExecuteSqlCommand(TransactionalBehavior.DoNotEnsureTransaction, "Archive @Day", daysparam);