Comment les informations d'identification de connexion ODBC sont-elles stockées dans MS Access?

Question

J'ai une base de données Access qui utilise un formulaire de connexion pour établir une connexion à SQL Server en utilisant ADODB.Connection. La chaîne de connexion contient les informations d'identification de l'utilisateur saisies dans le formulaire de connexion. Dans une situation d'accès normale, si une requête de passage est soumise avec des informations d'identification utilisateur dans la chaîne de connexion, Access enregistre les informations d'identification à utiliser par d'autres requêtes pendant la session, même si ces requêtes n'incluent pas les informations d'identification.

Je voudrais savoir comment je peux utiliser l'ADODB.Connection pour connecter un utilisateur et qu'Access utilise automatiquement les informations d'identification lors de l'envoi de requêtes de transfert.

Answer 1

Si vous avez utilisé une requête enregistrée pour la requête PT, cela fonctionne par défaut sans aucun effort. Et la même chose vaut pour les tables liées. Donc, si toutes vos requêtes PT et aussi TOUTES vos tables liées n'incluent PAS le login/mot de passe, alors comme vous notez ONCE vous exécutez "n'importe quoi" qui a l'ouverture de session/mot de passe, maintenant TOUTES requêtes, tables liées, et la requête PT utilisera automatiquement cette connexion/mot de passe mis en cache.

Ainsi, pour exécuter une requête de PT, vous pouvez aller à tout moment:

With CurrentDb.QueryDefs("MyPass") 
    qdfPass.SQL = "exec sp_myProc" 
    qdfPass.Execute 
End With 

Au-dessus est grande, puisque vous ne déconner avec les chaînes de connexion dans le code plus. et ci-dessus est FAR moins de code, puis des exemples ADO.

Vous devez donc utiliser les objets DAO intégrés pour tirer parti de l'utilisateur/mot de passe mis en cache. Il n'y a pas un moyen d'utiliser les reocrdsets ADO et ADO et puis "saisir" ou "faire usage" de cette ouverture de session/mot de passe mis en cache que Access a comme une chaîne de connexion. Donc, en utilisant l'accès au cache automatique, l'ouverture de session/mot de passe est un excellent moyen d'éviter d'inclure l'utilisateur/connexion dans n'importe quelle connexion au serveur SQL. Et cette approche signifie que AUCUNE de vos chaînes de connexion enregistrées doit inclure la connexion/utilisateur.

Cela signifie aussi que vous n'avez jamais à jouer avec des chaînes de connexion dans presque TOUS votre code. Un excellent moyen de centraliser le "concept" d'une connexion dans votre application et ne JAMAIS avoir à inclure login/utilisateur dans un tel code après une connexion unique.

Toutefois, à ma connaissance, il n'est pas possible d'extraire ou d'obtenir cette connexion en cache sous forme de chaîne dans VBA qui inclut cette information. Le résultat de ci-dessus signifie que vous préférez utiliser DAO et non ADO si possible, car aucun de vos codes dans l'application ne doit fournir ou gérer des chaînes de connexion.

Vous pouvez mettre en cache l'ouverture de session/utilisateur avec ce code:

Function TestLogin(strCon As String) As Boolean 
    ' return true for a correct logon 

    On Error GoTo TestError 

    Dim dbs   As DAO.Database 
    Dim qdf   As DAO.QueryDef 

    Set dbs = CurrentDb() 
    Set qdf = dbs.CreateQueryDef("") 

    qdf.Connect = strCon 

    qdf.ReturnsRecords = False 

'Any VALID SQL statement that runs on server will work below. 

qdf.SQL = "SELECT 1" 
qdf.Execute 

TestLogin = True 

Exit Function 

    TestError: 
     TestLogin = False 
     Exit Function 

End Function 

Je tiens également à souligner que cette fois que vous exécutez ce qui précède, il n'y a aucun moyen possible de vider le cache de mot de passe. Ceci suggère FORTEMENT que vous devez quitter l'application pour permettre à un autre utilisateur de se connecter. Vous n'avez pas besoin de quitter l'application, mais TOUTE chaîne de connexion fournie à la routine ci-dessus avec une connexion/utilisateur INCORRECT continuera à renvoyer True et suggérer que vous avez une connexion valide car si ci-dessus échoue, Access utilisera un cache de travail connexion/mot de passe pour ci-dessus et donc toujours retourner vrai - même pour une connexion/utilisateur incorrect. (donc passer une connexion/utilisateur correcte mettra en cache et retournera true - une connexion/utilisateur incorrect retournera vrai mais utilisera l'utilisateur du cache précédent !!).

Ce tout suggère bien que comme « genres » l'application approche de conception SI vous allez utiliser cette grande fonctionnalité de cache d'accès, vous limité à l'aide de la construction dans les objets qui sont basés DAO.