Il s'agit d'une série d'articles en six parties sur le traçage ODBC pour aider les développeurs Access à résoudre les problèmes et à travailler avec Access lors du développement d'une application qui utilise des sources de données ODBC, généralement mais pas exclusivement SQL Server. La série vise à montrer comment utiliser le traçage ODBC pour surveiller les instructions SQL ODBC qu'Access émet en arrière-plan lors de l'utilisation d'objets tels que des requêtes, des formulaires ou des rapports ou même lors de l'exécution de code VBA sur des objets DAO. La série montrera également comment Access formule les instructions SQL ODBC. Enfin, la série couvrira comment interpréter le traçage et identifier les problèmes potentiels. Les articles seront imprimés quotidiennement jusqu'à la fin de la série.
MISE À JOUR : Ajout d'une clé de registre pour l'installation de C2R 32 bits sur Windows 64 bits. Merci, Jack MacDonald !
Combien de fois avez-vous entendu « Je ne sais pas pourquoi, mais secouer la poignée fonctionne » ? Chaque fois que je reçois ce genre de réponse, cela m'irrite parce que c'est tellement insatisfaisant. Je serais très inquiet si mon plombier me disait qu'il ne savait pas qu'un p-trap est fait et qu'il continuait à l'appeler "ce truc tout en courbes sous l'évier". De même, mes clients devraient être très inquiets si je disais "Je ne sais pas pourquoi cette requête était lente, alors j'ai essayé quelques choses au hasard et bon, j'ai trouvé une astuce qui fonctionne. Je ne sais pas pourquoi, cependant. C'est peut-être l'un des plus grands fléaux du développement logiciel - nous travaillons avec un système complexe qui revient à basculer entre 0 et 1 très rapidement dans une certaine séquence et on s'attend à ce qu'il sache pourquoi il n'a pas fait de cette façon au lieu de cette façon.
Je pense que cela vaut la peine de consacrer du temps et de l'investissement au développeur travaillant avec Access et VBA pour savoir vraiment ce qu'il fait, en particulier avec un backend ODBC. Nous avons eu des scénarios de migration dans lesquels nous n'avons peut-être pas accès aux outils de profilage côté serveur pour différentes raisons, mais cela ne devrait pas être une raison pour hausser les épaules et écraser les boutons au hasard jusqu'à ce que quelque chose fonctionne. Plus important encore, avoir une solide compréhension de ce qui se passe sous le capot vous aide à mieux prédire les correctifs de performances que vous devez appliquer pour un scénario donné. Je soutiens que même si vous n'avez fait que lire la série et apprendre comment Access fonctionne avec les sources de données ODBC, vous serez bien mieux équipé simplement parce que vous savez ce qu'Access est susceptible de faire.
Pour les scénarios plus compliqués, le traçage peut généralement faire des merveilles en révélant pourquoi les choses fonctionnent si lentement. Étant donné que vous pouvez le suivre côté accès plutôt que sur le serveur, il ne nécessite pas d'autorisations élevées au-delà de l'accès à la clé de registre pour activer le suivi ODBC. Le bonus supplémentaire est que cela fonctionne pour toutes les sources de données ODBC, pas seulement SQL Server, donc si vous avez un client qui utilise MySQL ou PostgreSQL dont vous ne savez rien, le traçage ODBC vous aidera toujours à identifier les problèmes potentiels que vous pouvez ensuite résoudre directement sur Côté accès.
La série se concentrera uniquement dans le contexte d'Access et de DAO. Les choses peuvent être différentes lorsque nous utilisons ADO dans VBA, mais ce n'est pas dans la portée pour l'instant car chaque fois que nous utilisons DAO, Access fera plusieurs choses pour satisfaire nos demandes autrement impossibles. Un bon exemple est une requête Access qui fait référence à une fonction VBA. Vous ne pouvez pas exécuter la fonction VBA sur SQL Server, mais Access ne se plaint pas. Alors que se passe-t-il vraiment derrière le rideau ? Nous pouvons découvrir ce que fait Access en traçant les commandes SQL ODBC qu'il émet vers les sources de données ODBC.
La plupart des informations présentées dans cette série d'articles sont rendues possibles grâce à l'ancien livre blanc de Microsoft sur Jet &ODBC. Bien que je pense que l'information est toujours très bénéfique, elle est également assez dense et nécessite un haut niveau de compétence technique. On espère qu'en parcourant la série de traçage, cela aidera à donner du sens et à présenter les informations d'une manière plus accessible.
Pourquoi devrions-nous tracer ODBC ? Comment cela va-t-il m'aider ?
Si vous avez déjà ressenti l'un de ces symptômes :
Ou toute autre erreur lorsque vous travaillez avec une table liée ODBC, il est alors utile de comprendre pourquoi vous recevez ces messages et comment vous pouvez les corriger. Un correctif courant appliqué par plusieurs développeurs Access consiste à ajouter Requery ou à essayer de sauvegarder les enregistrements. Bien que cela puisse résoudre certains des problèmes, il n'est pas rare de voir un formulaire d'accès complexe être généreusement saupoudré de Requery et plusieurs chaînes d'événements en cascade que les performances commencent à souffrir. Au lieu de les saupoudrer comme s'il s'agissait de poussière de lutin magique, nous devrions être plus chirurgicaux dans nos approches pour résoudre les problèmes liés à l'application.
Une autre raison impérieuse est de pouvoir analyser pourquoi un formulaire A particulier prend 10 secondes pour s'ouvrir mais un formulaire B similaire ne prend que 2 secondes pour s'ouvrir. Au lieu de prendre le temps de mélanger les choses pour trouver ce qui fait que la forme A s'ouvre plus rapidement, vous pouvez commencer par tracer et comparer la différence, puis vous concentrer sur la différence pour vous aider à résoudre les problèmes de manière plus directe.
Même si nous ne finissons pas toujours par tracer chaque fois qu'il y a un problème de performances, avoir la connaissance de ce qu'Access doit faire est d'une immense valeur. Donc, même si tout ce que vous avez fait est de lire la série, j'espère que vous comprendrez mieux comment travailler avec Access plutôt que contre.
Accéder aux dialectes SQL et ODBC SQL
Avant d'entrer dans les détails, nous devons reconnaître que chaque fois qu'Access fonctionne avec une source de données ODBC, il doit d'abord traduire son instruction SQL en une instruction SQL ODBC valide. Ceci est distinct du dialecte SQL cible du backend (par exemple, SQL Server, Oracle, MySQL, PostgreSQL). La grammaire SQL ODBC est décrite ici. Vous pouvez également voir une liste de toutes les fonctions prises en charge par la couche ODBC. Il est important de se rappeler que lorsque nous utilisons ODBC, nous ne traduisons pas directement d'Access SQL vers le dialecte SQL natif de la source de données. Au lieu de cela, nous traduisons Access SQL en ODBC SQL que le pilote ODBC pour la source de données donnée traduira ensuite dans son dialecte natif. Si vous pouvez imaginer un locuteur japonais et un locuteur français qui ne parlent pas la langue de l'autre mais qui parlent tous les deux anglais, c'est essentiellement ce qui se passe sur la couche ODBC. Une autre conséquence est que ce n'est pas parce que le dialecte ODBC prend en charge la fonctionnalité X que l'un ou l'autre côté la prend en charge. Les deux côtés doivent prendre en charge cette fonctionnalité X pour qu'elle soit portable sur la couche ODBC. Heureusement, la plupart des pilotes ODBC sont assez larges et couvrent bien la plupart des fonctionnalités. Si vous rencontrez une situation où une fonctionnalité est censée fonctionner mais ne fonctionne pas, il peut être utile de consulter la documentation du pilote ODBC pour vérifier qu'elle est prise en charge.
Activation du traçage SQL ODBC
La première chose à faire pour que nous puissions jeter un coup d'œil derrière les rideaux est d'activer le traçage ODBC SQL. Bien que nous puissions utiliser SQL Server Profiler, il est très utile de voir comment Access formate le SQL ODBC. Cela fonctionnera avec toutes les sources de données ODBC et pas seulement avec SQL Server. Plus important encore, cela nous permet de voir comment Access traduit ses requêtes vers ODBC d'une manière plus directe que SQL Server Profiler ou d'autres outils de profilage côté serveur. Vous n'avez pas besoin d'autorisations spéciales pour utiliser le traçage ODBC SQL, tandis que les outils de profilage côté serveur peuvent nécessiter un niveau d'autorisation élevé pour être utilisés. L'activation du traçage ODBC SQL est un paramètre de registre, nous pouvons donc le configurer en accédant à la clé de registre appropriée :
Base de données Jet ou versions Office antérieures à 2007
Pour Windows 32 bits :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC
Pour le moteur Jet 32 bits ou Office antérieur à 2007 sous Windows 64 bits :
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC
Remarque :Il n'existe pas de version 64 bits du moteur Jet obsolète.
Office 2007 à 2016 (installations MSI)
Pour Office 32 bits sur Windows 32 bits ou Office 64 bits sur Windows 64 bits :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
Pour Office 32 bits sur Windows 64 bits :
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
(où X.Y correspond à la version d'Office que vous avez installée)
Office 2016 ou Office 365 (Cliquer pour exécuter)
Pour Office 32 bits sur Windows 32 bits ou Office 64 bits sur Windows 64 bits :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Pour Office 32 bits sur Windows 64 bits :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Sous la clé, localisez la clé TraceSQLMode et changez la valeur de 0 à 1 .
L'accès devra être redémarré s'il est déjà ouvert. Sinon, ouvrez-le et exécutez quelques requêtes. Un fichier nommé sqlout.txt sera créé dans le répertoire courant. Cela se trouve généralement dans le même dossier que le fichier Access OU dans le dossier des documents. Alternativement, vous pouvez exécuter la fonction VBA CurDir pour déterminer le répertoire courant.
Je recommande d'utiliser Notepad++ ou un éditeur de texte similaire qui a la capacité de détecter qu'il a été modifié. Il vous demandera alors de recharger le fichier. Cela vous permet d'afficher les nouvelles mises à jour au fur et à mesure qu'Access émet de nouvelles commandes dans le fichier texte sans réouverture constante. Lorsque vous activez le fichier texte, Notepad++ affiche une boîte de dialogue :
Vous pouvez ensuite cliquer sur Yes pour voir les dernières commandes SQL ODBC émises par Access. Étant donné qu'Access peut émettre plusieurs commandes SQL ODBC, le journal peut croître rapidement. Je trouve pratique d'arriver au point où je veux tracer quelque chose (par exemple, sur le point d'ouvrir un formulaire ou d'exécuter une requête), je passe ensuite au sqlout.txt , rechargez-le, puis sélectionnez tout, supprimez tout le texte, puis enregistrez le fichier désormais vide. De cette façon, je peux exécuter l'action que je veux tracer, puis ne voir que les commandes ODBC pertinentes sans tous les autres bruits qui n'ont rien à voir avec l'action en cours de trace.
Voici une vidéo rapide pour illustrer :
Conclusion
Vous avez appris à activer le traçage ODBC et à afficher la sortie générée par Access. Vous pouvez voir que vous pouvez collecter la sortie même à partir d'actions telles que la simple ouverture d'une table ou l'exécution d'une requête. Cela vous donne un aperçu du type de requêtes SQL qu'Access envoie réellement à la source de données ODBC.
Comme vous pouvez le voir, le traçage ODBC SQL capture toutes les commandes ODBC SQL émises par Access même si vous ne l'avez pas émis directement. Par conséquent, vous pouvez l'utiliser à tout moment où vous rencontrez des ralentissements pour lesquels vous n'avez pas une bonne explication. Par exemple, supposons que vous ayez un formulaire qui est lent à s'ouvrir et que vous n'êtes pas sûr que ce soit votre code VBA dans le formulaire Open ou Load événements ou la source d'enregistrement qui pose problème. Une stratégie serait de configurer l'application Access afin que vous soyez sur le point d'ouvrir ce formulaire, effacez le sqlout.txt fichier texte puis ouvrez le formulaire. Vous pouvez ensuite examiner les instructions SQL ODBC tracées et déterminer si certaines peuvent être améliorées.
Cela est particulièrement utile lorsque vous traitez un formulaire ou un rapport complexe qui contient également des sous-formulaires/sous-rapports ou contient des listes déroulantes ou des listes déroulantes qui émettent leurs propres requêtes pour satisfaire la propriété rowsource.
Dans le prochain article, nous analyserons la sortie lorsque nous parcourrons les enregistrements.
Besoin d'aide avec Microsoft Access ? Contactez notre équipe au 773-809-5456 ou envoyez-nous un e-mail à [email protected].
