Discussion :

[stigma]

Bonjour,
Malgré tous les articles et tutos sur le sujet, je m'y suis un peu perdu.
J'ai une base frontale ADO et mes tables sont sur SQL Server.2005
J'ai exporté mes tables existantes de Access vers le serveur SQL avec un fichier ODBC dsn :

Code :

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

1
2
3
4
5
6
7
8
9
10
[ODBC]
DRIVER=SQL Native Client
UID=Admin_GPersonnel
PWD=xxx
Network=DBMSSOCN
WSID=VERW0217
APP=Microsoft Data Access Components
SERVER=VERSSQL01.EU.BICWORLD.COM
DATABASE=GPersonnel
Description=Gestion personnel

Au démarrage de ma base frontale, je fais appel à un fichier udl qui contient la chaîne de connexion :

Code :

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

1
2
3
[oledb]
; Everything after this line is an OLE DB initstring
Provider=SQLOLEDB.1;Password=xxx;Persist Security Info=True;User ID=admin_gpersonnel;Initial Catalog=Securite;Data Source=VERSSQL01.eu.bicworld.com

A chaque démarrage de mon appli, si je veux ouvrir une table attaché j'ai le message :

Connexion à SQL Server
Le nom du serveur est bien :VERSSQL01.EU.BICWORLD.COM
Mais mon id de connexion est mon login du réseau de l'entreprise !

Il suffit que je tapes Admin_GPersonnel et le mot de passe pour toutes les tables soient accessibles.
J'appelle mon fichier udl ainsi à partir d'un module de démarrage :

Code :

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

1
2
3
    Set Cnx_DB = New ADODB.Connection
    Cnx_DB.ConnectionString = "FILE NAME=" + s_CheminBaseSecurite + LireINI(s_FichierINI, "Config", "FichierUDL")
    Cnx_DB.Open

Je pense qu'il suffirait d'une ligne de code au bon endroit pour résoudre mon problème mais ça fait une semaine que je patauge.
Merci pour votre aide bienvenue.

[LedZeppII]

Bonjour,

Qu'est que tu appelles "base frontale ADO" ? Est-ce une base mdb ou adp ?

Sinon, je note une différence au niveau du mode d'authentification SQL Server.
Avec ODBC le mode d'authentification utilisé est SQL Server.
Avec OLE DB c'est l'authentification Windows qui est utilisée.

Je fais l'hypothèse que ta base est de type mdb.
Si des tables ont été liées (via ODBC) avec le mode d'authentification SQL Server (UID et PWD dans la chaîne de connexion), sans l'option "enregistrer mot de passe", alors l'identifiant de connexion et le mot de passe sont demandés à la première connexion.

Etablir une connexion par code VBA ne résoud pas le problème, car Access va créer sa propre connexion et n'aura pas connaissance de la tienne.

Peut-être faudrait-il recréer les tables liées avec dans la chaîne de connexion ODBC

Code :

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

Trusted_Connection=Yes

à la place de

Code :

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

UID=Admin_GPersonnel;PWD=xxx

De cette manière c'est l'authentification Windows qui est choisie.
Il faut être sûr que chaque utilisateur (Windows) possède les autorisations nécessaires au niveau du serveur SQL Server.

Ou bien recréer les tables liées en enregistrant identifiant et mot de passe.

Code :

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

1
2
DoCmd.TransferDatabase typetransfert, typebase, nombase, typeobjet, _
              source, destination, structureseulement, enregcodeconnexion

Mettre True pour enregcodeconnexion

A+

[stigma]

Oui ma base frontale est un mdb développé en VBA ADO. Plus tard ce sera un mde bien sûr.
ça marche si je remplace UID et PWD par Trusted_Connection=Yes dans mon fichier DSN
Mais ça ne marche plus ensuite. Dois-je passer en sécurité intégrée NT au lieu du login et mot de passe dans mon fichier UDL ?

[LedZeppII]

Bonjour,

ODBC (pour les tables liées dans le mdb/mde) et ADO (provider SQLOLEDB) sont indépendants l'un de l'autre.
De plus les mot-clés de leurs chaînes de connexions respectives sont différents.
L'équivalent de Trusted_Connection=Yes (ODBC) est Integrated Security=SSPI pour ADO (provider SQLOLEDB).

Sinon, j'ai dit une bêtise concernant la connexion ADO (fichier udl).
L'authentification est de type SQL Server et non Windows. Désolé
Le problème initial devait venir de ce que les table liées ODBC ont été créées sans enregistrer le nom d'utilisateur SQL Server et le mot de passe.

Trusted_Connection=Yes a l'avantage de fonctionner, que l'option soit choisie ou pas.
Mais il y a un risque que le nom des tables ([schema_name.]object_name) ne soit pas reconnu dans ADO si le membre optionnel schema_name n'est pas présent.

En conclusion : ne change rien au fichier udl, ni au fichier dsn.
Recrée les tables liées ODBC, en t'assurant que l'option d'enregistrement du nom d'utilisateur et du mot de passe est activée.

A+

[stigma]

Un grand merci pour ton intervention. Maintenant ça roule