La connessione a SQL Server funziona a volte


100

Un'applicazione ADO.Net è solo talvolta in grado di connettersi a un altro server sulla rete locale. Sembra casuale se un determinato tentativo di connessione ha esito positivo o negativo. La connessione utilizza una stringa di connessione nella forma:

Server = THESERVER \ TheInstance; Database = TheDatabase; ID utente = TheUser; Password = ThePassword;

l'errore restituito è:

Timeout connessione scaduto. Il periodo di timeout è trascorso durante il tentativo di utilizzare il riconoscimento dell'handshake di pre-accesso.
Ciò potrebbe essere dovuto al fatto che l'handshake di pre-accesso non è riuscito o il server non è stato in grado di rispondere in tempo.
La durata spesa durante il tentativo di connessione a questo server è stata: inizializzazione [Pre-Login] = 42030; stretta di mano = 0;

L'applicazione .NET è una piccola app di test che esegue il codice seguente:

using (SqlConnection conn = new SqlConnection(cs))
using (SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM TheTable", conn))
{
    conn.Open();
    int rowCount = (int)cmd.ExecuteScalar();
}

La tabella è piccola, solo 78 righe.

Tuttavia, sulla stessa macchina in cui l'applicazione .NET riceve questo errore, sono in grado di connettersi a THESERVER utilizzando SSMS e l'ID utente / password indicati nella stringa di connessione.

Perché la connessione potrebbe non riuscire da un'app ADO.Net, ma riuscire con credenziali identiche da SSMS?


1

Risposte:


92

Si è scoperto che TCP / IP era abilitato per l'indirizzo IPv4, ma non per l'indirizzo IPv6, di THESERVER.

Apparentemente alcuni tentativi di connessione hanno finito per utilizzare IPv4 e altri hanno utilizzato IPv6.

L'abilitazione di TCP / IP per entrambe le versioni IP ha risolto il problema.

Il fatto che SSMS abbia funzionato si è rivelato casuale (i primi tentativi presumibilmente utilizzavano IPv4). Alcuni tentativi successivi di connessione tramite SSMS hanno restituito lo stesso messaggio di errore.

Per abilitare TCP / IP per indirizzi IP aggiuntivi:

  • Avvia Sql Server Configuration Manager
  • Aprire il nodo Configurazione di rete di SQL Server
  • Fare clic con il pulsante sinistro del mouse su Protocolli per MYSQLINSTANCE
  • Nel riquadro di destra, fare clic con il pulsante destro del mouse su TCP / IP
  • Fare clic su Proprietà
  • Seleziona la scheda Indirizzi IP
  • Per ogni indirizzo IP elencato, assicurati che Attivo e Abilitato siano entrambi Sì.

Grazie, questo ha risolto l'errore per me. È interessante notare che tutti gli indirizzi IP erano disabilitati (in precedenza non lo erano). Sarebbe bene sapere cosa può causare la disabilitazione di questi perché non penso che la configurazione sarà stata modificata manualmente nel mio caso ...
Matt

Neanche io ho mai disabilitato manualmente i miei indirizzi IPv6. Mi chiedo anche come siano finiti disabili.
Eric J.

Non sono in grado di abilitare l'IPv6 per qualche motivo. Dice che il servizio deve essere riavviato affinché le modifiche abbiano effetto, ma non lo mantiene mai come "Sì". Qualche indizio su come affrontarlo
Salman

5
Non sono sicuro che le singole voci disabilitate siano un problema poiché la scheda Protocollo ha un override "ascolta tutto" che dice a SQL di ascoltare su tutti gli IP. Vedere il seguente collegamento per la documentazione. msdn.microsoft.com/en-us/library/dd981060.aspx
shaneh

2
Sto vedendo questo genere di cose in Azure, credo
tofutim

31

Ho appena riscontrato lo stesso errore che si è allineato sospettosamente con l'ultimo ciclo di aggiornamenti Microsoft (09/02/2016). Ho scoperto che SSMS si è connesso senza problemi mentre la mia applicazione ASP.NET ha restituito il "periodo di timeout trascorso durante il tentativo di utilizzare il riconoscimento dell'handshake pre-accesso" errore

La soluzione per me era aggiungere un timeout di connessione di 30 secondi nella stringa di connessione, ad esempio:

ConnectionString="Data Source=xyz;Initial Catalog=xyz;Integrated Security=True;Connection Timeout=30;"

Nella mia situazione l'unica connessione interessata era quella che utilizzava la sicurezza integrata e stavo impersonando un utente prima di connettermi, altre connessioni allo stesso server utilizzando l'autenticazione SQL funzionavano bene!

2 sistemi di test (client separati e server Sql) sono stati colpiti contemporaneamente, inducendomi a sospettare un aggiornamento di Microsoft!


Ho avuto lo stesso problema, grazie per la risoluzione. Mi stavo connettendo utilizzando la sicurezza integrata tramite una VPN e l'aumento del timeout di connessione predefinito da 15 a 30 secondi ha risolto il problema per me.
Mark G

1
Ho avuto questo problema con SQL 2014 LocalDB dopo che setup.exe ha installato la nuova applicazione e il processo di avvio stava cercando di creare il nuovo database. Questa correzione mi ha salvato dallo sputare il manichino - grazie Shaun!
Scott

1
Questo ha risolto il problema anche per me. Nel mio caso mi stavo connettendo tramite VPN e aggiungendo una voce nel file hosts. Il problema si verificava solo quando si utilizzava il nome host nelle applicazioni SSMS e .NET. Quando si utilizza l'indirizzo IP, il problema non si è verificato.
Dan

GRAZIE PER QUESTA RISPOSTA!
Konrad

17

Ho risolto il problema come Eric ma con alcune altre modifiche:

  • Avvia Sql Server Configuration Manager
  • Aprire il nodo Configurazione di rete di SQL Server
  • Fare clic con il pulsante sinistro del mouse su Protocolli per MYSQLINSTANCE
  • Nel riquadro di destra, fare clic con il pulsante destro del mouse su TCP / IP
  • Fare clic su Proprietà
  • Seleziona la scheda Indirizzi IP
  • Per ogni indirizzo IP elencato, assicurati che Attivo e Abilitato siano entrambi Sì.

E

  • Per ogni indirizzo IP elencato, assicurati che TCP Dynamic Ports sia vuoto e TCP Port = 1433 (o qualche altra porta)
  • Apri Windows Firewall e verifica che la porta sia Aperta nelle connessioni in entrata

La soluzione non funziona per me. Ho un server che contiene il sito Web e il database e questo problema non si verifica mai su di esso, ma ho riscontrato questo problema quando il server Web è separato dal server del database
Ibrahim Amer

11

Ho avuto lo stesso problema, cercando di connettermi a un server in una rete locale (tramite VPN) da Visual Studio, durante la configurazione di un Entity Data Model.
Riuscito a risolvere solo impostando TransparentNetworkIPResolution=falsenella stringa di connessione. In VS Add Connection Wizard, puoi trovarlo nella scheda Avanzate.


3
L'impostazione è TransparentNetworkIPResolution = False. È una nuova funzionalità di .NET 4.6.1 ed è attiva per impostazione predefinita. L'impostazione di questo valore su false rimuoverà il timeout di 500 ms creato da questa funzione. Per ulteriori informazioni: blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/…
Jorriss

Grazie. Ore di ricerca su questo problema. Ho bisogno di aggiungere questa risposta ai preferiti. Il commento di @Jorriss è stato molto utile per capire il motivo. Tuttavia, potresti aggiornare la tua risposta per avere la parola chiave corretta. Jorriss ha il riferimento corretto.
TravisWhidden

5

Ho avuto lo stesso problema di stretta di mano durante la connessione a un server ospitato.

Ho aperto la rete e il centro di condivisione e ho abilitato IPv6 sulla mia connessione di rete wireless.

inserisci qui la descrizione dell'immagine


3

Il mio eseguibile che è stato creato utilizzando .NET Framework 3.5 ha iniziato a segnalare questi problemi di connessione in circa la metà delle volte dopo che alcuni aggiornamenti di Windows sono stati installati di recente (settimana del 7 agosto 2017).

Gli errori di connessione sono stati causati da .NET Framework 4.7 installato sul computer di destinazione (l'installazione automatica degli aggiornamenti di Windows era attiva): https://support.microsoft.com/?kbid=3186539

La disinstallazione di .NET Framework 4.7 ha risolto i problemi di connessione.

Apparentemente, c'è un cambiamento radicale in .Net Framework 4.6.1 - TransparentNetworkIPResolution L' aggiornamento della stringa di connessione come da articolo ha anche risolto il problema senza la necessità di ripristinare la versione del framework.


2

Ho corretto questo errore su Windows Server 2012 e SQL Server 2012 abilitando IPv6 e sbloccando la porta in entrata 1433.


1
Penso che questa non possa essere una risposta corretta perché la domanda contiene "solo a volte". Una porta bloccata non risolverà la domanda in merito.
Magier

2

Nel nostro caso si è verificato un problema a causa della configurazione del cluster di disponibilità. Per risolvere questo problema abbiamo dovuto impostareMultiSubnetFailover su True nella stringa di connessione.

Maggiori dettagli su MSDN


1

Ho avuto lo stesso problema, riesco a risolverlo aprendo / abilitando la porta 1433 e tcp / ip in SQL Server Configuration Manager e quindi riavviato il server

inserisci qui la descrizione dell'immagine


1

Nel mio caso soprattutto le opzioni c'erano già.

Risolto aumentando Timeout connessione = 30.SQL Server Management Studio


1

Prima di perdere altro tempo a risolvere il problema, come me, prova a riavviare il tuo computer Windows . Ha funzionato per me dopo aver applicato tutte le altre soluzioni.


0

Ho riscontrato questo problema durante la migrazione da SharePoint 2010 a 2013. Sospettavo che, poiché il server del database si trova dall'altra parte di un firewall che non instrada IP6, stava tentando di utilizzare IP6 e non riusciva durante la connessione al database.

Penso che il problema sia ora risolto. Gli errori sembrano essersi fermati. Quello che ho fatto è stato semplicemente disabilitare IP6 (deselezionandolo) per la scheda di rete sui server SharePoint.


0

Ho avuto lo stesso problema, ma mi stavo connettendo a un database remoto utilizzando un indirizzo IP statico. Quindi nessuna delle soluzioni di cui sopra ha risolto il mio problema.

Non ero riuscito ad aggiungere la mappatura utente corretta per l'accesso di sicurezza che stavo utilizzando, quindi la soluzione per me era semplicemente assicurarmi che l'impostazione Mappatura utente fosse impostata per accedere al mio database.


0

Risolto questo problema bloccando / inserendo nella lista nera gli indirizzi IP che cercavano di forzare gli account utente. Controlla i tuoi log di accesso SQL per un gran numero di tentativi di accesso non riusciti (di solito per l'account "sa").


0

Per me, risulta che il firewall nel server Windows stava bloccando la porta 1433 che è la porta del server sql predefinita. Quindi l'aggiunta di una regola in entrata per accettare quelle connessioni ha reso il trucco per me.


0

Nel mio caso, Persist Security Info=trueil problema è causato dal parametro con l'utente e la password nella stringa di connessione. Rimozione del parametro o set per falserisolvere il problema.


0

Prova un semplice riavvio di SQL Server prima di eseguire qualsiasi operazione drastica. Potrebbe aggiustarlo. Lo ha fatto per me


0

Sfortunatamente, ho avuto problemi con SQL Server locale installato in Visual Studio e qui molte soluzioni non hanno funzionato per me. Tutto quello che devo fare è reimpostare il mio Visual Studio, andando su:

Pannello di controllo> Programmi e funzionalità> Avvio installazione di Visual Studio

e fare clic sul pulsante Altro e scegliere Ripara

Successivamente sono stato in grado di accedere al mio SQL Server locale e lavorare con i database SQL locali.


0

Ho avuto lo stesso problema che si risolve automaticamente dopo l'ultimo aggiornamento di Microsoft Windows, qualcuno ha lo stesso?


0

Ho avuto il problema esatto, ho provato diversi soultion non funzionava, infine ho riavviato il sistema, ha funzionato bene.


0

Per tracciare l' errore "Timeout connessione scaduto" , assicurati che:

Per maggiori dettagli, controlla Timeout connessione scaduto. Il periodo di timeout è trascorso durante il tentativo di utilizzare il riconoscimento dell'handshake di pre-accesso


Quale di questi casi ha a che fare con errori intermittenti?
RonJohn

Si prega di modificare per rivelare l'affiliazione, è obbligatorio . Grazie.
Maximillian Laumeister

0

Aggiunta di una risposta qui, nonostante la risposta precedentemente accettata. Poiché il mio scenario è stato confermato come DNS. Più specificamente, un timeout DNS durante l'handshake di pre-accesso. Passando da un nome DNS a un indirizzo IP (o utilizzando la voce del file Hosts), si aggira il problema. Anche se a costo di perdere la risoluzione ip automatica.

Ad esempio, anche con il valore di timeout di una stringa di connessione impostato su 60 per un minuto intero, si verificherà comunque entro un paio di secondi dal tentativo. Il che porta a chiedersi perché dovrebbe scadere prima del periodo di timeout specificato? DNS.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.