Discussion :

[droliprane]

Bonjour à tous,

je suis nouveau sur le forum, ça fait 15 jours que je me suis mis au VB.NET pour développer une GPAO sur mesure pour la boite où je travaille. Je développe en VB2005 Express et base Sql Server 2005.

Le serveur Sql est hébergé sur mon poste de développement, mon appli tourne bien en local mais lorsque je la déploie sur le réseau, je reçois l'erreur suivante au premier appel de connexion au serveur Sql :

Message Win98 : COMException (0x80004005): [Microsoft][ODBC SQL Server Driver] Le client n'a pas pu établir la connexion

Message XP Pro : COMException (0x80004005): [Microsoft][ODBC SQL Server Driver] [DBNETLIB] Ce serveur SQL n'existe pas ou son accès est refusé

Je suis allé fouiner du côté des chaines de connexion, mais je suis perdu au niveau des technologies employées : ODBC, ADODB, OleDB, ...

J'ai choisi de passer par ADODB parce que je viens de l'ASP et du VBA et que c'est la méthode que j'utilisais jusqu'alors. D'autre part je trouve pratique le système des Recordset... Dernière chose : j'aimerais vraiment conserver cette logique d'objet Connection, Recordset, ... vu que l'appli est déjà bien avancée et que je me vois mal tout reprendre.

Donc, pour que vous puissiez m'aider je vous mets un extrait du code qui me sert à me connecter à mon serveur SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
Dim Conn As ADODB.Connection
 
Private Sub ConnectBD()
 
        'Paramètres de connexion via ADODB
        Dim NomUtilisateur, MotDePasse, NomServeur, NomBaseDeDonnees As String
        NomUtilisateur = "sa"
        MotDePasse = "1123581321"
        NomServeur = "10.1.0.23\SQLEXPRESS"
        NomBaseDeDonnees = "GPAO"
 
        'Instanciation de l'objet Connection
        Conn = New ADODB.Connection()
 
        'Définition de la chaîne de connexion
        Conn.ConnectionString = "UID=" & NomUtilisateur & ";PWD=" & MotDePasse & ";" & "DRIVER={SQL Server};Server=" & NomServeur & ";Database=" & NomBaseDeDonnees & ";"
 
        'Etablissement de la connexion
        Conn.Open()
 
End Sub

Ce code s'exécute sans problème en local sur le poste qui héberge SQL Server, en revanche dès que j'ai exécute mon appli déployée sur un autre poste du réseau, j'ai les erreurs citées précédemment.

J'ajoute pour finir que Sql Server est bien configuré pour accepté les connexions TCP/IP ou cannaux nommés, et que SQL Browser est actif aussi.

J'espère que vous saurez m'aider. N'hésitez pas s'il le faut à me demander plus de précisions sur mon environnement de travail.

Bob

[neptune]

Ton message d'erreur est pourtant clair, est-ce qu'avec exactement la même connection string tu arrives à t'y connecter avec un outil SQL externe?

Sinon, dommage de faire de l'ADO plutot que de l'ADO.NET :'-(

[bobby51]

plutot que d'utiliser un nom d'utilisateur et un mot de passe, utilise integrated security = true. Dessous une chaine de connexion qui marche
connectionString="Data Source=10.1.0.23\SQLEXPRESS;Initial Catalog=GPAO;Integrated Security=true;Pooling=False"
tu n'a besoin que de ca avec sql server normalement
je te conseille aussi de mettre ta chaine de connexion dans app.config

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<connectionStrings>
        <add name="NomduProjet.My.MySettings.GPAO"
           connectionString="Data Source=10.1.0.23\SQLEXPRESS;Initial Catalog=GPAO;Integrated Security=true;Pooling=False"
            providerName="System.Data.SqlClient" />
    </connectionStrings>

puis de l'appeler avec dim connexion As New SqlConnection(My.Settings.GPAO)
Moi je fait comme ca et ca marche niquel

[neptune]

Heuu, non, on peut comprendre qu'il ait besoin d'une utilisateur spécifique et de son mot de passe.

[bobby51]

oui mais si il le rentre en dur il sert plus à rien son nom d'utilisateur et son mot de passe
Et meme si il laisse le nom et le mot de passe, je ne voit pas pourquoi sa chaine de connexion est si compliqué

[neptune]

Ne vois pas que l'aspect authentification, mais également l'aspect autorisation. Son utilisateur particulier n'a peut-être que des droits restreints sur la DB. (Ce qui dit en passant est à mon sens une excellente pratique).

De plus, imagine que tu déploie l'application sur le net via un serveur mutualisé...

[bobby51]

Son utilisateur particulier n'a peut-être que des droits restreints sur la DB.

ba il pourrait restreindre l'accès a la base au niveau du code et non pas au niveau de la base elle meme

imagine que tu déploie l'application sur le net via un serveur mutualisé

désolé je connai pas
Mais bon on s'éloigne un peu du sujet
moi ce que je trouve bizarre c'est le DRIVER={SQL Server}
jamais eu besoin de ca pour une connexion à sqlserver!
dit moi bvadam, tu utilise bien System.Data.SqlClient pour manipuler ta base?
de plus tu fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Conn = New ADODB.Connection()

avec sql server c'est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dim connexion As New SqlConnection

SQL SERVER est le plus simple pour intérargir avec vb, tu n'a pas besoin d'utiliser AdoDB

[neptune]

Il a dit explicitement qu'il fait de l'ADO et pas de l'ADO.NET...

[droliprane]

Tout à fait. Je suis parti avec la même logique de développement que lorsque je faisais de l'asp ou du VB, donc j'utilise la bibliothèque ADODB et ses objets Connexion et Recordset. Je suis habitué à manipuler ces objets et pour le moment ça me gêne d'employer la bibliothèque SqlClient et ses DataAdapter, DataReader et compagnie. Peut-être que je franchirai le pas un jour, mais toujours est-il que le fait de rester en ADO ne devrait pas empêcher une instance distante de mon application de se connecter à mon server SQL...

Là je suis en train de faire des tests au niveau des ports, et je me rends compte qu'un simple telnet localhost 1433 ne passe pas. J'ai une install de SQL Server avec l'instance par défaut, donc port TCP 1433, connections TCP activées, sql browser activé, ... Le pare-feu sur le serveur et sur la machine cliente ont été désactivés à des fins de tests mais toujours la même erreur. Là je suis en train de regarder du coté du port dynamique...

Vraiment pas limpide la mise en réseau de SQL Server !

[bobby51]

désolé j'avai du le lire mais j'avai oublé
dans ce cas pour ADO je peux pas t'aider je n'ai jamais utilisé
mais si un jour tu decide de franchir le pas tu ne sera pas décu, c'est vraiment simple a utiliser ( en tout cas plus simple qu'avec ce que tu utilise )

[droliprane]

Bon ben voilà je viens de trouver.

Je suis allé fouttre mon nez dans le Sql Server Configuration Manager :
- Configuration du réseau SQL Server 2005
- Protocole pour SQLEXPRESS
- propriétés du protocole TCP/IP
- onglet "Adresses IP"
- section "IP All"
- Ports TCP Dynamiques
- et là attribuer un port. j'ai laissé le port proposé : 1092

Ma procédure de connexion devient donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Public Sub ConnectBD(ByRef Conn As ADODB.Connection)
 
        'Paramètres de connexion via ADODB
        Dim NomUtilisateur, MotDePasse, NomServeur, NomBaseDeDonnees As String
        NomUtilisateur = "sa"
        MotDePasse = "1123581321"
        NomServeur = "10.1.0.23\SQLEXPRESS,1092"
        NomBaseDeDonnees = "GPAO"
 
 
        'Définition de la chaîne de connexion
        Conn = New ADODB.Connection()
 
        ' Connexion String
        Conn.ConnectionString = "UID=" & NomUtilisateur & ";PWD=" & MotDePasse & ";" & "DRIVER={SQL Server};Server=" & NomServeur & ";Database=" & NomBaseDeDonnees & ";"
 
        'Ouverture de la base de données
        Conn.Open()
 
End Sub

Maintenant j'attaque le serveur SQL aussi bien en local que depuis les instances déployées. J'ai trouvé beaucoup de doc sur le paramétrage de SQL Server pour activer les connexions distantes mais aucune ne parlait du port TCP dynamique, je suis tombé dessus vraiment par hasard. Coup de chance.