MS Access 2003 + tables liées à SQL Server 2005 + Windows Authentification = lent

Question

Notre application MS Access avec des tables liées à SQL Server 2005 est lente lors de l'utilisation de l'authentification Windows à partir de clients Windows XP.

Nous l'avons exécuté avec succès en utilisant l'authentification SQL Server, mais maintenant nous voulons passer à l'authentification Windows pour un meilleur contrôle de la sécurité.

Configuration:

• serveur de base de données: Windows 2003 Server, SQL Server 2005 SP2
• Client: Windows XP SP3, pilote ODBC SQL Server v2000.85.1132.00
• d'application MS Access: MS Access 2003
• chaîne de connexion:
  DRIVER=SQL Server;SERVER=[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
• Seul le protocole réseau TCP/IP est activé sur le serveur.

La lenteur ne pas se produire dans ces situations:

• App sur le serveur DB, l'authentification SQL Server
• App sur le serveur DB, l'authentification Windows
• App sur le client Windows XP, Authentification SQL Server
• SQL Server Management Studio sur le client, Authentification Windows - J'ai effectué un petit test en exécutant 15 requêtes dans SQL MS. Cela s'est passé rapidement et n'a provoqué aucun événement de connexion/déconnexion dans le journal des événements de sécurité sur le serveur.

J'ai analysé la lenteur à l'aide de profils SQL Server et le journal des événements sur le serveur et il semble se résumer à ceci:

1. L'application exécute une requête
2. Une nouvelle connexion SQL Server est ouvert (visible dans SQL Server Profiler)
3. L'identité de l'utilisateur est vérifiée (visible dans le journal des événements de sécurité sur le serveur, un événement de connexion/déconnexion se produit). Cela prend plusieurs centaines de millisecondes.
4. La requête est exécutée sur SQL Server
5. Les résultats sont renvoyés à Access

Cela se produit pour chaque requête. Certains des formulaires exécutent + - 10 requêtes lors de l'affichage d'un nouvel enregistrement (mise à jour de sous-formulaires, chargement de valeurs pour les combos, etc.). Cela entraîne des performances très lentes.

Bien sûr, la configuration d'une nouvelle connexion à SQL Server pour chaque requête n'est pas nécessaire et la réutilisation des connexions peut résoudre le problème. J'ai cherché des informations sur la façon de s'assurer qu'Access/ODBC effectue correctement la mise en commun des connexions. J'ai trouvé ces articles MS KB:

Frequently Asked Questions About ODBC Connection Pooling
How to Enable Connection Pooling in an ODBC Application

J'ai essayé d'appeler la fonction SQLSetEnvAttr de la forme principale de l'application d'accès, mais cela n'a pas amélioré les résultats.

Toute aide est grandement appréciée.

Answer 1

Vérifiez client Microsoft SQL Server Native à http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en

Answer 2

La première question est: êtes-vous en cours d'exécution d'un contrôleur de domaine? Cela peut sembler une question folle, mais je veux juste m'assurer. Bien que de moins en moins répandu, j'ai vu des organisations exécuter des réseaux Windows avec des groupes de travail et l'authentification "pass-through". Les symptômes que vous décrivez sont les mêmes que ceux observés sur un réseau configuré de cette manière.

En supposant que vous ayez un domaine correctement configuré, vous devez avoir un problème quelque part dans la pile réseau Canaux nommés. Named Pipes est le protocole par défaut si vous utilisez l'authentification Windows. Ce n'est pas une mauvaise idée d'aller au fond de ce si vous avez le temps, mais si vous voulez juste pour résoudre votre problème de performance, alors je forcerait le protocole TCP/IP dans votre chaîne de connexion:

DRIVER=SQL Server;SERVER=tcp:[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name] 

Notez l'ajout du préfixe tcp:. J'ai obtenu cette syntaxe de Jon Galloway's blog. TCP/IP est le protocole par défaut pour l'authentification SQL Server. Vous pouvez également faire basculer le protocole en désactivant la prise en charge des tubes nommés sur le serveur, mais cela pose plus de problèmes et peut entraîner d'autres problèmes imprévus.