J'ai récemment installé SQL Server 2012. Aucune base de données n'a encore été créée. Et je peux ouvrir le Management Studio avec sa / password. Le Binn \ sqlservr.exe est démarré en tant que service et je peux le voir démarré dans la liste des services. Cependant, il n'écoutait pas le port 1433, ou même, n'écoutant aucun port par défaut, comme je l'ai vérifié comme ci-dessous:

tasklist|find /I "sql"

J'ai eu:

sqlservr.exe                  5668 Services                   0     40,112 K

dans lequel 5668 je pense est le PID. Et puis pour obtenir PID = "5668", c'est écouter quel port:

netstat -ano | find /I "5668"

mais je n'ai rien sauf un blanc. D'autre part, après avoir recherché des publications sur ce site, j'ai revérifié la configuration de mon SQL Server: démarrer-> Tous les programmes -> Microsoft SQL Server 2012 -> Outils de configuration -> SQL Server Configuration Manager-> SQL Server SQL Native Client 11.0 Configuration -> Protocoles client -> TCP / IP -> Port par défaut 1433. Il existe 3 services, SQL Server (MyInstanceName), SQL Server Agent (MyInstanceName) et SQL Server Browser. Les deux derniers sont arrêtés.

Gestionnaire de configuration SQL Server-> Configuration réseau SQL Server-> Protocoles pour MyInstanceName -> TCP / IP est désactivé par défaut, après l'avoir activé et redémarrer le service et répéter le netstat -ano | find / I "newPIDNum" commande J'ai trouvé le

TCP    0.0.0.0:52395          0.0.0.0:0              LISTENING  5668(newPIDNum)   

Pourquoi 52395 au lieu de 1433? Et je n'ai pas réussi à créer le DSN à l'aide de l'administrateur de source de données ODBC Windows qui me renvoie une erreur: serveur SQL spécifié introuvable. Une aide pour moi? Merci.

Ce qui a amené mon serveur SQL à écouter les TCPconnexions sur le port 1433 était le suivant ...

1. Outils de configuration / Gestionnaire de configuration SQL Server
2. cliquez sur le nom de l'instance dans la configuration réseau de SQL Server
3. permettre la TCPcommunication
4. Cliquez avec le bouton droit sur l' TCPentrée de communication, choisissezProperties
5. Cliquez sur l'onglet adresses IP
6. Activez toutes les adresses IP non VMnet et entrez 1433 dans l' Portentrée " IPAll ".
7. Redémarrez SQL Server sur l'onglet Services SQL Server

8. Vérifiez votre configuration avec netstat -an:

   C:\>netstat -an | find "1433"
     TCP    0.0.0.0:1433           0.0.0.0:0              LISTENING
     TCP    [::]:1433              [::]:0                 LISTENING

Pourquoi 52395 au lieu de 1433

Les instances nommées écoutent sur les ports dynamiques. Est le travail du service Sql Server Browser pour informer les clients du port réel. Le navigateur SQL écoute sur UDP 1434 et répond aux questions de la forme «quel est le port d'écoute de l'instance« foo »?». Le service SQL Server Browser est requis pour les protocoles TCP et les canaux nommés. Les clients utilisent le navigateur SQL Server de manière transparente, pas besoin de configuration spéciale. En spécifiant simplement un nom d'instance dans la chaîne de connexion (ou le DSN ODBC), la bibliothèque cliente doit d'abord contacter le service SQL Server Browser.

Il existe 3 services, SQL Server (MyInstanceName), SQL Server Agent (MyInstanceName) et SQL Server Browser. Les deux derniers sont arrêtés

De toute évidence, pour que SQL Server Browser fasse son travail, il doit être démarré. Démarrez-le et changez le type de démarrage en automatique.

En remarque, une configuration alternative souvent utilisée consiste à utiliser des ports statiques pour l'instance nommée et à spécifier le port dans la chaîne de connexion ( tcp:<hostname>:<port>). Il a l'avantage de retirer le navigateur SQL Server de l'équation, mais il nécessite une maintenance minutieuse des clients. La modification du port d'écoute nécessite des changements orchestrés sur tous les clients, toutes les machines, tous les emplacements, généralement une grande douleur. Je recommande plutôt de prendre la dépendance du navigateur SQL Server.

Pare-feu - 3 d'entre eux

Les personnes qui ne sont pas familières avec les versions plus récentes de Windows (je ne suis pas à l'aise avec aucune après XP et essayais d'installer SQL Server sur Windows 10):

• Votre pare-feu doit être désactivé à 3 endroits différents (c'est-à-dire pour 3 profils différents).

Si vous ne le faites que pour le premier que vous voyez (profil de domaine), vous vous demanderez toujours pourquoi vous pouvez vous connecter au port 80 (IIS) mais pas au 1433 (SQL Server).

Je ne peux pas encore commenter (réputation faible car pas très active): mais désactiver le pare-feu Windows, comme mentionné ci-dessus, est la pire réponse possible. Le correct serait: Créer des règles de pare-feu en "entrant" pour permettre la communication du port 1433 sur les IP locales (ou toutes) dont vous avez besoin. Et je recommande également de définir les adresses IP distantes autorisées à se connecter à ce serveur SQL.