La connexion à SQL Server fonctionne parfois


101

Une application ADO.Net ne peut que parfois se connecter à un autre serveur sur le réseau local. Il semble aléatoire qu'une tentative de connexion donnée réussisse ou échoue. La connexion utilise une chaîne de connexion sous la forme:

Serveur = THESERVER \ TheInstance; Database = TheDatabase; User Id = TheUser; Mot de passe = ThePassword;

l'erreur renvoyée est:

Délai de connexion expiré. Le délai d'expiration s'est écoulé lors de la tentative d'utilisation de l'accusé de réception de la prise de contact préalable à la connexion.
Cela peut être dû au fait que l'établissement de liaison préalable à la connexion a échoué ou que le serveur n'a pas pu répondre à temps.
La durée passée lors de la tentative de connexion à ce serveur était - [Pre-Login] initialization = 42030; poignée de main = 0;

L'application .NET est une petite application de test qui exécute le code suivant:

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

La table est petit, seulement 78 lignes.

Cependant, sur la même machine où l'application .NET reçoit cette erreur, je peux me connecter à THESERVER en utilisant SSMS et l'ID utilisateur / mot de passe nommé dans la chaîne de connexion.

Pourquoi la connexion peut-elle échouer à partir d'une application ADO.Net, mais réussir avec des informations d'identification identiques de SSMS?


1
vous rencontrez peut-être un problème mentionné dans blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/…
pardeepk

Réponses:


93

Il s'est avéré que TCP / IP était activé pour l'adresse IPv4, mais pas pour l'adresse IPv6, de THESERVER.

Apparemment, certaines tentatives de connexion ont fini par utiliser IPv4 et d'autres ont utilisé IPv6.

L'activation de TCP / IP pour les deux versions IP a résolu le problème.

Le fait que SSMS a fonctionné s'est avéré être une coïncidence (les premières tentatives utilisaient probablement IPv4). Certaines tentatives ultérieures de connexion via SSMS ont abouti au même message d'erreur.

Pour activer TCP / IP pour des adresses IP supplémentaires:

  • Démarrez Sql Server Configuration Manager
  • Ouvrez le nœud Configuration réseau SQL Server
  • Protocoles de clic gauche pour MYSQLINSTANCE
  • Dans le volet de droite, cliquez avec le bouton droit sur TCP / IP
  • Cliquez sur Propriétés
  • Sélectionnez l'onglet Adresses IP
  • Pour chaque adresse IP répertoriée, assurez-vous que Actif et Activé sont tous les deux Oui.

Merci, cela a résolu l'erreur pour moi. Fait intéressant, toutes les adresses IP étaient désactivées (auparavant, elles ne l'étaient pas). Il serait bon de savoir ce qui peut entraîner leur désactivation car je ne pense pas que la configuration aura été modifiée manuellement dans mon cas ...
Matt

Je n'ai jamais non plus désactivé manuellement mes adresses IPv6. Je me demande aussi comment ils ont fini par être handicapés.
Eric J.

Je ne parviens pas à activer IPv6 pour une raison quelconque. Il indique que le service doit être redémarré pour que les modifications prennent effet, mais il ne le conserve jamais comme "Oui". Tous les indices sur la façon de s'y prendre
Salman

5
Je ne suis pas sûr que les entrées individuelles désactivées soient un problème car l'onglet Protocole a un remplacement «écouter tout» qui indique à SQL d'écouter sur toutes les adresses IP. Voir le lien suivant pour la documentation. msdn.microsoft.com/en-us/library/dd981060.aspx
ShaneH

2
Je vois ce genre de chose dans Azure je pense
tofutim

31

J'ai eu la même erreur qui vient de se produire, qui s'est alignée de manière suspecte sur la dernière série de mises à jour de Microsoft (09/02/2016). J'ai constaté que SSMS s'était connecté sans problème alors que mon application ASP.NET renvoyait l'erreur «Délai d'expiration écoulé lors de la tentative de consommation de l'accusé de réception de la prise de contact avant la connexion»

La solution pour moi était d'ajouter un délai d'expiration de connexion de 30 secondes dans la chaîne de connexion, par exemple:

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

Dans ma situation, la seule connexion affectée était celle qui utilisait la sécurité intégrée et j'empruntais l'identité d'un utilisateur avant de me connecter, d'autres connexions au même serveur utilisant l'authentification SQL fonctionnaient bien!

2 systèmes de test (clients distincts et serveurs Sql) ont été affectés en même temps, ce qui m'a amené à suspecter une mise à jour de Microsoft!


J'ai eu le même problème, merci pour la résolution. Je me connectais en utilisant la sécurité intégrée via un VPN et l'augmentation du délai de connexion par défaut de 15 à 30 secondes a résolu le problème pour moi.
Mark G le

1
J'ai eu ce problème avec SQL 2014 LocalDB après que setup.exe ait installé la nouvelle application et que le processus de démarrage essayait de créer la nouvelle base de données. Ce correctif m'a évité de cracher le mannequin - merci Shaun!
Scott

1
Cela a également résolu le problème pour moi. Dans mon cas, je me connectais via VPN et ajoutais une entrée dans le fichier hosts. Le problème ne s'est produit que lors de l'utilisation du nom d'hôte dans les applications SSMS et .NET. Lors de l'utilisation de l'adresse IP, le problème ne s'est pas produit.
Dan

MERCI POUR CETTE RÉPONSE!
Konrad

17

J'ai résolu le problème comme Eric mais avec quelques autres changements:

  • Démarrez Sql Server Configuration Manager
  • Ouvrez le nœud Configuration réseau SQL Server
  • Protocoles de clic gauche pour MYSQLINSTANCE
  • Dans le volet de droite, cliquez avec le bouton droit sur TCP / IP
  • Cliquez sur Propriétés
  • Sélectionnez l'onglet Adresses IP
  • Pour chaque adresse IP répertoriée, assurez-vous que Actif et Activé sont tous les deux Oui.

ET

  • Pour chaque adresse IP répertoriée, assurez-vous que TCP Dynamic Ports est vide et TCP Port = 1433 (ou un autre port)
  • Ouvrez le pare-feu Windows et vérifiez que le port est ouvert dans les connexions entrantes

La solution ne fonctionne pas pour moi. J'ai un serveur qui contient le site Web et la base de données et ce problème ne se produit jamais dessus, mais j'ai trouvé ce problème lorsque le serveur Web est séparé du serveur de base de données
Ibrahim Amer

11

J'ai eu le même problème, en essayant de me connecter à un serveur dans un réseau local (via VPN) à partir de Visual Studio, lors de la configuration d'un modèle de données d'entité.
Géré pour résoudre uniquement en définissant TransparentNetworkIPResolution=falsedans la chaîne de connexion. Dans VS Add Connection Wizard, vous pouvez le trouver dans l'onglet Advanced.


3
Le paramètre est TransparentNetworkIPResolution = False. C'est une nouvelle fonctionnalité à partir de .NET 4.6.1 et est activée par défaut. La définition de ce paramètre sur false supprimera le délai de 500 ms créé par cette fonctionnalité. Pour plus d'informations: blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/…
Jorriss

Je vous remercie. Des heures de recherche sur ce problème. Je dois mettre cette réponse en favori. Le commentaire de @Jorriss a été très utile pour comprendre pourquoi. Vous pouvez mettre à jour votre réponse pour avoir le mot clé correct. Jorriss a la bonne référence.
TravisWhidden le

5

J'ai eu le même problème de poignée de main lors de la connexion à un serveur hébergé.

J'ai ouvert mon centre de réseau et de partage et activé IPv6 sur ma connexion réseau sans fil.

entrez la description de l'image ici


3

Mon exécutable qui a été créé à l'aide de .NET Framework 3.5 a commencé à signaler ces problèmes de connexion environ la moitié des fois après l'installation récente de certaines mises à jour Windows (semaine du 7 août 2017).

Les échecs de connexion ont été causés par .NET Framework 4.7 qui a été installé sur l'ordinateur cible (l'installation automatique des mises à jour Windows était activée) - https://support.microsoft.com/?kbid=3186539

La désinstallation de .NET Framework 4.7 a résolu les problèmes de connexion.

Apparemment, il y a un changement radical dans .Net Framework 4.6.1 - TransparentNetworkIPResolution La mise à jour de la chaîne de connexion selon l'article a également résolu le problème sans qu'il soit nécessaire de restaurer la version du framework.


2

J'ai corrigé cette erreur sur Windows Server 2012 et SQL Server 2012 en activant IPv6 et en débloquant le port entrant 1433.


1
Je pense que cela ne peut pas être une réponse correcte car la question contient "seulement parfois". Un port bloqué ne répondra pas à la question à ce sujet.
Magier

2

Dans notre cas, un problème est survenu en raison de la configuration du cluster de disponibilité. Pour résoudre ce problème, nous avons dû définir MultiSubnetFailoversur True dans la chaîne de connexion.

Plus de détails sur MSDN


1

J'ai eu le même problème, j'ai réussi à le résoudre en ouvrant / activant le port 1433 et tcp / ip dans SQL Server Configuration Manager, puis j'ai redémarré le serveur

entrez la description de l'image ici


1

Dans mon cas, toutes les options étaient déjà là.

Résolu le problème en augmentant le délai d'expiration de la connexion = 30.Studio de gestion SQL Server


1

Avant de perdre plus de temps à résoudre le problème, comme moi, essayez simplement de redémarrer votre machine Windows . A travaillé pour moi après avoir appliqué toutes les autres solutions.


0

J'ai eu ce problème lorsque j'ai effectué une migration de SharePoint 2010 vers 2013. Je soupçonnais cela parce que le serveur de base de données est de l'autre côté d'un pare-feu qui n'achemine pas IP6 qu'il essayait alors d'utiliser IP6 et échouait lors de la connexion à la base de données.

Je pense que le problème est maintenant résolu. Les erreurs semblent avoir cessé. Ce que j'ai fait, c'est simplement désactiver IP6 (en le décochant) pour la carte réseau sur les serveurs SharePoint.


0

J'ai eu ce même problème, mais je me connectais à une base de données distante en utilisant une adresse IP statique. Aucune des solutions ci-dessus n'a donc résolu mon problème.

Je n'avais pas réussi à ajouter le mappage utilisateur approprié pour la connexion de sécurité que j'utilisais, donc la solution pour moi était simplement de m'assurer que le paramètre de mappage utilisateur était défini pour accéder à ma base de données.


0

Résolution de ce problème en bloquant / en mettant sur liste noire les adresses IP qui tentaient de forcer les comptes d'utilisateurs par force brute. Vérifiez vos journaux d'accès SQL pour un grand nombre de tentatives de connexion infructueuses (généralement pour le compte «sa»).


0

Pour moi, il s'avère que le pare-feu du serveur Windows bloquait le port 1433, qui est le port du serveur SQL par défaut. Donc, ajouter une règle entrante pour accepter ces connexions a fait l'affaire pour moi.


0

Dans mon cas, le paramètre Persist Security Info=trueavec l'utilisateur et le mot de passe dans la chaîne de connexion est à l'origine du problème. Suppression du paramètre ou défini pour falserésoudre le problème.


0

Essayez d'abord un simple redémarrage de SQL Server avant de faire quelque chose de radical. Pourrait le réparer. Ça l'a fait pour moi


0

Malheureusement, j'ai eu un problème avec Local SQL Server installé dans Visual Studio et ici, de nombreuses solutions n'ont pas fonctionné pour moi. Tout ce que j'ai à faire est de réinitialiser mon Visual Studio, en allant sur:

Panneau de configuration> Programme et fonctionnalités> Lanceur d'installation de Visual Studio

et cliquez sur le bouton Plus et choisissez Réparer

Après cela, j'ai pu accéder à mon serveur SQL local et travailler avec des bases de données SQL locales.


0

J'ai eu le même problème qui se résout automatiquement après la dernière mise à jour de Microsoft Windows, est-ce que quelqu'un rencontre le même problème?


0

J'ai eu le problème exact, essayé plusieurs soultion ne fonctionnait pas, enfin redémarré le système, cela fonctionnait bien.


0

Pour suivre l' erreur "Délai de connexion expiré" , veuillez vous assurer que:

Pour plus de détails, veuillez vérifier Délai de connexion expiré. Le délai d'expiration s'est écoulé lors de la tentative de consommation de l'accusé de réception de la prise de contact avant la connexion


Lequel de ces cas est lié à des erreurs intermittentes?
RonJohn

Veuillez modifier pour divulguer l'affiliation, c'est obligatoire . Merci.
Maximillian Laumeister

0

Ajout d'une réponse ici, malgré la réponse précédemment acceptée. Comme mon scénario a été confirmé comme étant DNS. Plus précisément, un délai dns pendant la négociation de pré-connexion. En passant d'un nom DNS à une adresse IP (ou en utilisant l'entrée de fichier Hosts), vous contournez le problème. Mais au prix de la perte de la résolution IP automatique.

Par exemple, même avec la valeur de délai d'expiration d'une chaîne de connexion définie sur 60 pendant une minute complète, cela se produirait toujours dans les quelques secondes suivant la tentative. Ce qui amène à se demander pourquoi ce délai d'expiration avant la période de temporisation spécifiée? DNS.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.