La connexion à SQL Server fonctionne parfois

An ADO.Net l'application est seulement parfois capable de se connecter à un autre serveur sur le réseau local. Il semble aléatoire si une tentative de connexion donnée réussit ou échoue. La connexion utilise une chaîne de connexion sous la forme:

Server=THESERVERTheInstance;Base de données: la base de données;Id Utilisateur=Utilisateur; Mot de passe=ThePassword;

L'erreur renvoyée est:

Le Délai De Connexion A Expiré. Le délai d'attente s'est écoulé lors de la tentative de pré-ouverture de session poignée de main accusé de réception.
Cela peut être dû à l'échec de la négociation de pré-connexion ou à l'impossibilité pour le serveur de répondre à temps.
La durée passée lors de la tentative de connexion à ce serveur était-[pré-connexion] initialization = 42030; handshake=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 petite, seulement 78 lignes.

Cependant, sur le même machine où le. net l'application reçoit cette erreur, je suis capable de me connecter au serveur en utilisant SSMS et L'Id utilisateur/mot de passe nommé dans la chaîne de connexion.

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

81
demandé sur Eric J. 2013-03-19 03:34:29

14 réponses

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 ont probablement utilisé IPv4). Certaines tentatives ultérieures de connexion via SSMS ont donné lieu au même message d'erreur.

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

  • Démarrer Sql Server Configuration Manager
  • ouvrez le noeud SQL Server Network Configuration
  • 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 Active et Enabled sont tous deux Oui.
81
répondu Eric J. 2014-06-04 15:39:00

J'ai eu la même erreur qui s'est alignée de manière suspecte avec la dernière série de mises à jour de Microsoft (09/02/2016). J'ai trouvé que SSMS connecté sans problème pendant que mon ASP.NET l'application a renvoyé l'erreur "délai d'attente écoulé lors de la tentative de consommation de l'accusé de réception de pré-connexion"

La solution pour moi était d'ajouter un délai 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 était en utilisant la sécurité intégrée et je me faisais passer pour 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 microsoft!

23
répondu Shaun Keon 2017-10-25 12:58:11

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

  • Démarrer Sql Server Configuration Manager
  • Ouvrez le noeud SQL Server Network Configuration
  • 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 Active et Enabled sont tous deux Oui.

Et

  • pour chaque adresse IP répertoriée, assurez-vous 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
15
répondu Renzo Ciot 2015-04-15 12:35:49

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, tout en configurant un modèle de données D'entité.
Réussi à résoudre uniquement en définissant TransparentNetworkIPResolution=false dans la chaîne de connexion. Dans VS Add Connection Wizard, vous pouvez le trouver dans L'onglet Avancé.

6
répondu maozx 2018-09-26 10:05:55

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

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

entrez la description de l'image ici

5
répondu Pomster 2013-09-20 10:33:40

Mon exécutable qui a été construit en utilisant. NET Framework 3.5 a commencé à signaler ces problèmes de connexion dans environ la moitié des cas 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 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, là est un changement de rupture 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 avoir besoin de restaurer la version du framework.

3
répondu user270576 2017-08-17 14:36:25

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

2
répondu smwikipedia 2014-06-04 15:37:39

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 redémarré le serveur

entrez la description de l'image ici

1
répondu Myk Agustin 2016-02-19 02:32:02

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

L'A Résolu en augmentant le délai de connexion = 30.Studio de gestion de serveur SQL

1
répondu Jignesh 2017-04-26 08:10:03

J'ai eu ce problème quand j'ai fait une migration SharePoint 2010 à 2013. Je soupçonnais que parce que le serveur de base de données est de l'autre côté d'un pare-feu qui n'achemine pas IP6, 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ésactivé IP6 (en le décochant) pour la carte réseau sur les serveurs SharePoint.

0
répondu Chuck Herrington 2016-05-04 20:12:34

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

J'avais échoué à 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épondu John Livermore 2016-11-29 03:21:51

L'erreur" délai de connexion expiré " se produit généralement dans les cas suivants

  • une instance du moteur de base de données SQL Server n'est pas en cours d'exécution.
  • le service de navigateur SQL Server n'est pas en cours d'exécution.
  • Le TCP / IP est désactivé.
  • le nom du serveur a été saisi incorrectement.
  • Il y a des problèmes de réseau.
  • le port TCP/IP de L'instance du moteur de base de données est bloqué par un pare-feu.
  • le client et le serveur ne sont pas configurés pour protocole réseau.

Pour vérifier comment tracer cette erreur en fonction des raisons ci-dessus, vérifiez le délai D'expiration de la connexion a expiré. Le délai d'attente s'est écoulé lors de la tentative de consommation de l'accusé de réception de pré-connexion

0
répondu Mohamed El-Qassas MVP 2017-01-30 20:43:22

Résolu ce problème en bloquant / blacklisting adresse IP qui tentaient de forcer les comptes d'utilisateurs. Vérifiez vos journaux D'accès SQL pour un grand nombre de tentatives de connexion échouées(généralement pour le compte 'sa').

0
répondu user3424480 2017-07-06 21:22:09

Pour moi, il s'avère que le pare-feu dans windows server bloquait le port 1433 qui est le port sql server par défaut. Donc, l'ajout d'une règle entrante pour accepter ces connexions a fait l'affaire pour moi.

0
répondu Josué Zatarain Espinosa 2018-09-12 22:14:58