SQL Azure + Errore "C'è già un DataReader aperto associato a questo comando ..", anche dopo aver impostato "MultipleActiveResultSets = True"

Question

Ci troviamo di fronte a qualche problema con la versione distribuita della nostra applicazione su cloud.

La nostra applicazione è un progetto ASP.NET MVC 3 con ADO .NET Entity Framework.

In base ai blog msdn, è necessario aggiungere il parametro "MultipleActiveResultSets = True" (per Entity Framework con SQL azzurro) nella nostra stringa di connessione al database che abbiamo giustamente fatto.

otteniamo la seguente eccezione durante l'esecuzione di una query di database dalla nostra applicazione: '' Esiste già un DataReader aperto associato con questo comando che deve essere chiuso prima “, che credo sia molto relativa ai. 'MultipleActiveResultSets = True 'proprietà.

L'applicazione funziona perfettamente nell'ambiente locale con il nostro database distribuito localmente e utilizzando il database SQL di Azure (in ambiente locale).

Ma quando distribuiamo la nostra applicazione di cloud otteniamo l'errore sopra menzionato. Sembra che la proprietà 'MultipleActiveResultSets = True' non venga letta dalla stringa di connessione.

La stringa di connessione che sto usando è la seguente:

<connectionStrings> 
     <add name="#DBInstanceName#" connectionString="Data Source=tcp:#server#.database.windows.net,1433;Initial Catalog=#DBName#;User ID=”UserName#@#server#;Password=”#password#”;MultipleActiveResultSets=True" providerName="System.Data.SqlClient"/> 
    </connectionStrings> 

io sono in grado di connettersi al database SQL Azure utilizzando la stringa di connessione sopra dall'applicazione distribuito a livello locale, senza alcuna eccezione. Ma la stessa applicazione, quando distribuita su cloud utilizzando la stessa stringa di connessione, mi dà l'errore sopra citato.

Potete aiutarci a risolvere lo stesso?

Answer 1

Provare ad assegnare MultipleActiveResultSets nel codice. Non è letto o non funziona?

SqlConnectionStringBuilder.MultipleActiveResultSets

Answer 2

Non è necessario impostare multipleresultsets = true nel connectionsstring e riavviare.

Rimosso risposta

Edit: Questo è discusso! Controlla il commento sotto ... Non ho avuto il tempo di cercare ...

Penso che sia già acceso.

non ho potuto trovare un posto-on fonte, ma Faisal Mohamood (Program Manager, Entity Framework) afferma quanto segue nel 2010: "Inutile dire, faremo in modo che Marte viene attivata automaticamente per SQL App basate su Azure quando ci spostiamo per rilasciare il prossimo aggiornamento al prodotto ". Trovato qui: http://blogs.msdn.com/b/adonet/archive/2010/06/09/remember-to-re-enable-mars-in-your-sql-azure-based-ef-apps.aspx

Answer 3

Ho appena avuto lo stesso problema. Ho provato a impostare "MultipleActiveResultSets = True" nella connessione Web.config - nessun risultato. Infine ho risolto il problema modificando manualmente la stringa di connessione direttamente in Azure Dashboard per il sito Web: nella scheda "Configura" sono presenti le impostazioni "Stringhe di connessione" in cui è necessario aggiungere manualmente "MultipleActiveResultSets = True;" stringa. Dopo aver fatto ciò, MARS ha lavorato finalmente.

Answer 4

Ho lo stesso problema, ma ho risolto MultipleActiveResultSets = True nella stringa di connessione da pubblicare assistente, come Irium

Answer 5

In alternativa è possibile aggiungere il "MultipleActiveResultSets = true" per la stringa di connessione e aggiornare il Web di destinazione. config quando si utilizza la funzionalità Pubblica in Visual Studio. Assicurati di selezionare "Usa questa stringa di connessione in fase di esecuzione (aggiornamento destinazione web.config)."

Answer 6

Siamo sul nuovo portale di Azure e abbiamo avuto anche questo problema. MARS ha funzionato su tutti gli ambienti di sviluppo locali, ma ha gettato la stessa brutta eccezione su Azure. Abbiamo verificato che la stringa di connessione nel file web.config fisico distribuito in Azure contenesse MultipleActiveResultSets=true; ma non sembra essere onorato dall'applicazione. In ultima analisi, ciò che ha funzionato era l'istanza del servizio app> impostazioni> connessioni dati e l'eliminazione della connessione dati con lo stesso nome di quella in questione nel web.config. La mia ipotesi è quella che gli archivi di Azure superano quello del web.config distribuito.