Errore MSSQL ‘Il provider sottostante non è riuscito su Apri’

Stavo usando un .mdf per la connessione a un database e entityClient . Ora voglio cambiare la stringa di connessione in modo che non ci sarà nessun file .mdf .

La seguente connectionString corretta?

  <!---->  

Perché ottengo sempre l’errore:

Il provider sottostante non è riuscito in Open

Ho avuto questo errore e ho trovato alcune soluzioni:

Guardando la tua stringa di connessione, sembra valida. Ho trovato questo post sul blog , il problema è che stavano usando Integrated Security . Se si utilizza IIS, l’utente IIS deve accedere al database.

Se si utilizza Entity Framework con Transactions , Entity Framework apre e chiude automaticamente una connessione con ciascuna chiamata al database. Quindi, quando si utilizzano le transazioni, si sta tentando di diffondere una transazione su più connessioni. Questo eleva a MSDTC .

( Vedi questo riferimento per ulteriori informazioni. )

Cambiando il mio codice al seguente fisso:

 using (DatabaseEntities context = new DatabaseEntities()) { context.Connection.Open(); // the rest } 

context.Connection.Open() non ha aiutato a risolvere il mio problema, quindi ho provato a abilitare “Consenti client remoti” nella configurazione di DTC, niente più errori.

In Windows 7 è ansible aprire la configurazione di DTC eseguendo dcomcnfg, Servizi componenti -> Computer -> Risorse del computer -> Distributed Transaction Coordinator -> Fare clic con il pulsante destro del mouse su DTC locale -> Sicurezza.

Ho scoperto che il problema era che avevo il percorso del server all’interno della stringa di connessione in una di queste varianti:

 SERVER\SQLEXPRESS SERVER 

Quando davvero dovrei avere:

 .\SQLEXPRESS 

Per qualche ragione ho avuto l’errore ogni volta che ha avuto difficoltà a localizzare l’istanza di SQL.

Dovresti vedere innerException per vedere quale sia la causa interna del lancio dell’errore.

Nel mio caso, l’errore originale era:

Imansible aprire il file fisico “D: \ Projects2 \ xCU \ xCU \ App_Data \ xCUData_log.ldf”. Errore del sistema operativo 5: “5 (Accesso negato).”. Un tentativo di colbind un database con nome automatico per il file D: \ Projects2 \ xCU \ xCU \ App_Data \ xCUData.mdf non è riuscito. Esiste un database con lo stesso nome o il file specificato non può essere aperto oppure si trova sulla condivisione UNC.

che ha risolto dando il pieno permesso all’utente corrente per accedere ai relativi file mdf e ldf usando le proprietà dei file.

Questo è solo un problema comune. Anche io ho affrontato questo problema. Sul computer di sviluppo, configurato con l’autenticazione di Windows, funziona perfettamente:

  

Una volta ospitato in IIS con la stessa configurazione, ho ricevuto questo errore:

Il provider sottostante non è riuscito in Open

È stato risolto il cambio di connectionString nel file di configurazione:

  

Altri errori comuni potrebbero essere:

  1. Il servizio di database potrebbe essere arrestato
  2. Attributi dell’origine dati che puntano a un database locale con autenticazione Windows e ospitati in IIS
  3. Username e password potrebbero essere sbagliati.

Quando ricevi questa eccezione, assicurati di espandere i dettagli e guarda i dettagli delle eccezioni interne in quanto fornirà dettagli sul perché l’accesso non è riuscito. Nel mio caso la stringa di connessione conteneva un utente che non aveva accesso al mio database.

Indipendentemente dal fatto che si utilizzi Integrated Security (il contesto dell’utente Windows connesso) o un singolo account SQL, assicurarsi che l’utente abbia un accesso corretto in “Sicurezza” per il database a cui si sta tentando di accedere per evitare questo problema.

Ho avuto un problema simile con SQL Server Express Edition su Windows Server 2003 . Ho semplicemente aggiunto il servizio di rete come utente nella sicurezza del database.

Ciò può anche accadere se si ripristina un database e l’utente esiste già con uno schema diverso, lasciando l’utente in grado di assegnare le autorizzazioni corrette.

Per correggere questa corsa:

 USE your_database EXEC sp_change_users_login 'Auto_Fix', 'user', NULL, 'cf' GO EXEC sp_change_users_login 'update_one', 'user', 'user' GO 

Il servizio SQL Server Express non è stato impostato per il tostart automaticamente.

1) Vai al pannello di controllo 2) Strumenti di amministrazione 3) Servizio 4) Impostare SQL Server Express per avviarlo automaticamente facendo clic su di esso 5) Fare clic con il pulsante destro del mouse e avviare il servizio

Spero che possa aiutarti.

Assicurarsi che ogni valore di elemento nella stringa di connessione fornita sia corretto. Nel mio caso, stavo ottenendo lo stesso errore perché il nome del catalogo (nome del database) specificato nella stringa di connessione era errato.

Ho avuto un problema simile con le eccezioni dovute allo stato della connessione, quindi mi sono reso conto che avevo la mia variabile di class del servizio di dominio contrassegnata come statica (per errore).

La mia ipotesi è che una volta caricata la memoria del servizio in memoria, ogni nuova chiamata finisca per utilizzare lo stesso valore di variabile statica (istanza del servizio di dominio), causando conflitti tramite lo stato della connessione.

Penso anche che ogni chiamata client abbia generato un nuovo thread, quindi più thread che accedono alla stessa istanza del servizio di dominio equivalevano a un naufragio del treno.

Ho pubblicato un problema simile qui, lavorando con un db SQL 2012 ospitato su Amazon RDS. Il problema era nella stringa di connessione – avevo le proprietà “Nome applicazione” e “App” lì. Una volta rimossi quelle, ha funzionato.

Entity Framework 5 e Amazon RDS – “Il provider sottostante non è riuscito in Open.”

Ho avuto un errore simile con l’eccezione interna come di seguito:

operazione non è valida per lo stato della transazione

Potrei risolverlo abilitando le impostazioni di sicurezza DTC.

Vai a Proprietà di DTC, sotto Scheda Sicurezza, controlla quanto segue

  • Accesso DTC di rete
  • Consenti a RemoteClients
  • Comunicazione del gestore delle transazioni
  • Consenti in entrata
  • Consenti in uscita

Se ti capita di ottenere questo errore su un’applicazione web ASP.NET, oltre alle altre cose citate verifica quanto segue:

  1. Permessi di sicurezza dell’utente del database (a quali utenti è consentito l’accesso al proprio database.
  2. Controllare il pool di applicazioni in IIS e assicurarsi che sia quello corretto a cui è consentito l’accesso al database.

Mi sono liberato di questo resettando IIS , ma usando ancora Integrated Authentication nella stringa di connessione.

La definizione di una nuova regola di Windows Firewall per SQL Server (e per la porta 1433) sulla macchina server risolve questo errore (se il proprio nomeserver, nome utente o password dell’utente non sono errati nella stringa di connessione …).

Ho avuto lo stesso problema, ma quello che ha funzionato per me è stato rimuovere questo dalla stringa di connessione:

persist security info=True

Un errore comune che ho commesso perché stavo spostando l’applicazione da un PC a un altro e nessuno dei precedenti funzionava era che mi sono dimenticato di copiare la stringa di connessione su App.Config e su Web.Config!

Ho avuto un problema simile: nelle esecuzioni dei miei casi di test ho sempre avuto questo errore. Ho scoperto che il mio “Distributed Transaction Service” non era stato avviato (eseguire: services.msc -> avviare “Distributed Transaction Service” (meglio impostarlo per l’avvio automatico)). Dopo averlo fatto, ha funzionato come un incantesimo …

Ho copiato i file del database (.mdf / .ldf) nella cartella App_Data per eliminare questa eccezione.

Stavo anche affrontando lo stesso problema. Ora l’ho fatto rimuovendo il nome utente e la password dalla stringa di connessione.

Per me è stato solo un semplice errore:

Ho usato Amazon EC2 e ho usato il mio indirizzo IP elastico nella stringa di connessione, ma quando ho cambiato gli indirizzi IP ho dimenticato di aggiornare la mia stringa di connessione.

Ho avuto questo errore improvvisamente accaduto inaspettatamente su uno dei nostri siti. Nel mio caso, si è scoperto che la password dell’utente SQL era scaduta! Deselezionare la casella scadenza password in SQL Server Management Studio ha fatto il trucco!

Ho avuto lo stesso problema pochi giorni fa, usando “Integrated Security = True;” nella stringa di connessione è necessario eseguire l’id quadro del pool di applicazioni in “localsystem”. Sure questo non è raccomandato ma per il test fa il lavoro.

Ecco come è ansible modificare l’id quadro in IIS 7: http://www.iis.net/learn/manage/configuring-security/application-pool-identities

In IIS impostare l’ id quadro del pool di app come account utente del servizio o account amministratore o account della formica che dispone dell’authorization per eseguire l’operazione su tale base dati.

Nel mio caso ho avuto una mancata corrispondenza tra il nome della stringa di connessione che stavo registrando nel costruttore del contesto e il nome nel mio web.config. Semplice errore causato da copia e incolla: D

  public DataContext() : base(nameOrConnectionString: "ConnStringName") { Database.SetInitializer(null); } 

Ho lo stesso errore che ho trovato quando ho cambiato la mia connectionString in una nuova Data Source ho dimenticato di cambiare Username e passowrd per il nuovo database

Ho anche riscontrato questo errore se il nome dell’istanza di SQL Server non è specificato e l’host SQL ha più istanze SQL installate. Ecco alcuni esempi per chiarire:

La stringa di connessione riportata sotto comporta l’eccezione “Il provider sottostante non è riuscito all’apertura” senza alcuna eccezione interna in un’app. WebForms .NET:

  connectionString="metadata=res://*/Entities.csdl|res://*/Entities.ssdl|res://*/Entities.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=Entities;User ID=user;Password=password;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" 

La seguente stringa di connessione viene eseguita come previsto in un’app .net WebForms in cui l’ambiente SQL ha più istanze. Raro lo so, ma ho alcune diverse istanze SQL sul mio box di sviluppo per ospitare diversi progetti:

  connectionString="metadata=res://*/Entities.csdl|res://*/Entities.ssdl|res://*/Entities.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost\SQLSERVER2014;Initial Catalog=Entities;User ID=user;Password=password;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" 

nel mio caso l’indirizzo del server è stato modificato dall’amministratore del server, quindi ho dovuto cambiare la stringa di connessione con il nuovo indirizzo del server

Ho avuto questo problema perché il login del Pool di Applicazioni in cui questa app era in esecuzione era cambiato.

In IIS:

  • Trova il pool di applicazioni facendo clic sul tuo sito e andando su Impostazioni di base.

  • Vai a Pool di applicazioni.

  • Fai clic sul pool di applicazioni del tuo sito.

  • Clicca su Impostazioni avanzate.

  • In Identity framework, inserire login e password dell’account.

  • Riavvia il tuo sito e riprova.