Esta es una serie de artículos de seis partes sobre el seguimiento de ODBC para ayudar a los desarrolladores de Access a solucionar problemas y trabajar con Access al desarrollar una aplicación que usa fuentes de datos ODBC, por lo general, pero no exclusivamente, SQL Server. La serie tiene como objetivo demostrar cómo usar el seguimiento ODBC para monitorear las declaraciones SQL ODBC que Access emite en segundo plano cuando se trabaja con objetos como consultas, formularios o informes, o incluso cuando se ejecuta código VBA en objetos DAO. La serie también mostrará cómo Access formula las declaraciones SQL de ODBC. Finalmente, la serie cubrirá cómo interpretar el trazado e identificar problemas potenciales. Los artículos se imprimirán diariamente hasta que concluya la serie.
ACTUALIZACIÓN: Se agregó una clave de registro para la instalación de C2R de 32 bits en Windows de 64 bits. ¡Gracias, Jack MacDonald!
¿Cuántas veces has escuchado "No sé por qué, pero mover el mango simplemente funciona"? Cada vez que recibo ese tipo de respuesta, me irrita porque es muy insatisfactorio. Me preocuparía mucho si mi plomero me dijera que no sabe para qué sirve un sifón y siguiera refiriéndose a él como "esa cosa con curvas debajo del fregadero". Del mismo modo, mis clientes deberían estar muy preocupados si dijera:"No sé por qué esa consulta fue lenta, así que probé algunas cosas al azar y encontré un truco que funciona". Aunque no sé por qué. Posiblemente sea una de las mayores pesadillas del desarrollo de software:estamos trabajando con un sistema complejo que equivale a cambiar entre 0 y 1 muy rápidamente en una secuencia determinada y se espera que sepamos por qué no lo hizo de esa manera en lugar de esta.
Creo que vale la pena el tiempo y la inversión para que el desarrollador que trabaja con Access y VBA sepa realmente lo que está haciendo, especialmente con un backend ODBC. Hemos tenido escenarios de migración en los que es posible que no tengamos acceso a las herramientas de creación de perfiles del lado del servidor por diferentes motivos, pero eso no debería ser motivo para encogernos de hombros y simplemente mezclar botones al azar hasta que algo funcione. Más importante aún, tener una comprensión sólida de lo que sucede debajo del capó lo ayuda a ser mucho mejor para predecir qué correcciones de rendimiento necesita aplicar para un escenario determinado. Afirmo que incluso si todo lo que hizo fue leer la serie y aprender cómo funciona Access con fuentes de datos ODBC, estará mucho mejor equipado simplemente porque sabe qué es probable que haga Access.
Para escenarios más complicados, el rastreo generalmente puede hacer maravillas al revelar por qué las cosas funcionan tan lentamente. Debido a que puede rastrearlo en el lado de acceso en lugar de en el servidor, no requiere permisos elevados más allá de tener acceso a la clave de registro para habilitar el rastreo de ODBC. La ventaja adicional es que esto funciona para cualquier fuente de datos ODBC, no solo para SQL Server, por lo que si tiene un cliente que usa MySQL o PostgreSQL del que no sabe nada, el seguimiento de ODBC aún lo ayudará a identificar problemas potenciales que luego puede abordar directamente en Lado de acceso.
La serie se enfocará únicamente desde el contexto de Access y DAO. Las cosas pueden ser diferentes cuando usamos ADO en VBA, pero eso no está dentro del alcance por ahora porque cada vez que usamos DAO, Access hará varias cosas para satisfacer nuestras solicitudes que de otro modo serían imposibles. Un buen ejemplo es una consulta de Access que hace referencia a una función de VBA. No puede ejecutar la función VBA en SQL Server, pero Access no se queja. Entonces, ¿qué está pasando realmente detrás de la cortina? Podemos descubrir qué está haciendo Access rastreando los comandos SQL de ODBC que emite a las fuentes de datos de ODBC.
Gran parte de la información presentada en esta serie de artículos es posible con la ayuda del antiguo documento técnico de Microsoft sobre Jet y ODBC. Aunque creo que la información sigue siendo muy beneficiosa, también es bastante densa y requiere un alto nivel de competencia técnica. Se espera que al pasar por la serie de rastreo, ayude a tener sentido y presente la información de una manera más accesible.
¿Por qué debemos rastrear ODBC? ¿Cómo me ayudará?
Si alguna vez ha experimentado alguno de esos síntomas:
O cualquier otro error al trabajar con una tabla vinculada ODBC, entonces es beneficioso comprender por qué recibe esos mensajes y cómo puede corregirlos. Una solución común que aplican varios desarrolladores de Access es agregar Requery o intentar guardar los registros. Si bien eso podría resolver algunos de los problemas, no es raro ver un formulario de acceso complejo que se salpica generosamente con Requery y varias cadenas de eventos en cascada que el rendimiento comienza a sufrir. En lugar de rociarlos como si fueran polvo mágico, deberíamos ser más quirúrgicos en nuestros enfoques para solucionar problemas con la aplicación.
Otra razón convincente es poder analizar por qué un formulario A en particular tarda 10 segundos en abrirse pero un formulario B similar solo 2 segundos en abrirse. En lugar de tomarse el tiempo de mezclar las cosas para encontrar qué hace que el formulario A se abra más rápido, puede comenzar por rastrear y comparar la diferencia y luego enfocarse en la diferencia para ayudarlo a solucionar los problemas de una manera más directa.
Incluso si no siempre terminamos rastreando cada vez que hay problemas de rendimiento, tener la familiaridad de lo que debe hacer Access es de gran valor. Entonces, incluso si todo lo que ha hecho es leer la serie, con suerte tendrá una mejor apreciación de cómo trabajar con Access en lugar de en contra.
Acceso a dialectos SQL y ODBC SQL
Antes de entrar en detalles, debemos reconocer que cada vez que Access trabaja con una fuente de datos ODBC, primero debe traducir su declaración SQL en una declaración SQL ODBC válida. Esto es distinto del dialecto SQL de destino del backend (por ejemplo, SQL Server, Oracle, MySQL, PostgreSQL). La gramática SQL de ODBC se describe aquí. También puede ver una lista de todas las funciones compatibles con la capa ODBC. Es importante recordar que cuando usamos ODBC, en realidad no estamos traduciendo directamente de Access SQL al dialecto SQL nativo de la fuente de datos. Más bien, estamos traduciendo Access SQL a ODBC SQL que el controlador ODBC para la fuente de datos dada luego traducirá a su dialecto nativo. Si puede imaginar un hablante de japonés y un hablante de francés que no hablan el idioma del otro pero ambos hablan inglés, eso es básicamente lo que está sucediendo en la capa ODBC. Otra consecuencia es que el hecho de que el dialecto ODBC admita la característica X no significa que ninguno de los dos lados la admita. Ambos lados deben admitir esa característica X para que sea portátil sobre la capa ODBC. Afortunadamente, la mayoría de los controladores ODBC que existen son bastante amplios y hacen un buen trabajo al cubrir la mayoría de las funciones. Si se encuentra con una situación en la que se supone que una característica funciona pero no lo hace, puede ser útil consultar la documentación del controlador ODBC para verificar que sea compatible.
Habilitación del seguimiento SQL de ODBC
Lo primero que debe hacer para que podamos mirar detrás de las cortinas es habilitar el seguimiento SQL de ODBC. Aunque podemos usar SQL Server Profiler, ver cómo Access formatea el ODBC SQL es muy útil. Funcionará con cualquier fuente de datos ODBC y no solo con SQL Server. Más importante aún, esto nos permite ver cómo Access está traduciendo sus consultas a ODBC de una manera más directa que SQL Server Profiler u otras herramientas de generación de perfiles del lado del servidor. No necesita ningún permiso especial para usar el seguimiento SQL de ODBC, mientras que las herramientas de creación de perfiles del lado del servidor pueden requerir un alto nivel de permiso para usar. La habilitación del seguimiento SQL de ODBC es una configuración de registro, por lo que podemos configurarla accediendo a la clave de registro adecuada:
Base de datos Jet o versiones de Office anteriores a 2007
Para Windows de 32 bits:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC
Para motor Jet de 32 bits u Office anterior a 2007 en Windows de 64 bits:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC
Nota:No existe una versión de 64 bits del motor Jet en desuso.
Office 2007 a 2016 (instalaciones de MSI)
Para Office de 32 bits en Windows de 32 bits u Office de 64 bits en Windows de 64 bits:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
Para Office de 32 bits en Windows de 64 bits:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
(donde X.Y corresponde a la versión de Office que tiene instalada)
Office 2016 u Office 365 (hacer clic para ejecutar)
Para Office de 32 bits en Windows de 32 bits u Office de 64 bits en Windows de 64 bits:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Para Office de 32 bits en Windows de 64 bits:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Debajo de la clave, busque la clave TraceSQLMode y cambie el valor de 0 a 1 .
El acceso deberá reiniciarse si ya está abierto. De lo contrario, ábralo y ejecute algunas consultas. Un archivo llamado sqlout.txt se creará en el directorio actual. Por lo general, se encuentra en la misma carpeta que el archivo de Access O en la carpeta de documentos. Alternativamente, puede ejecutar la función VBA CurDir para determinar el directorio actual.
Recomiendo usar Notepad++ o un editor de texto similar que tenga la capacidad de detectar que fue modificado. A continuación, le pedirá que vuelva a cargar el archivo. Eso le permite ver nuevas actualizaciones a medida que Access emite nuevos comandos al archivo de texto sin tener que volver a abrirlo constantemente. Cuando active el archivo de texto, Notepad++ mostrará un cuadro de diálogo:
Puede hacer clic en Yes para ver los últimos comandos ODBC SQL emitidos por Access. Debido a que Access puede emitir varios comandos SQL de ODBC, el registro puede crecer rápidamente. Encuentro conveniente llegar al punto en el que quiero rastrear algo (por ejemplo, a punto de abrir un formulario o ejecutar una consulta), luego cambio a sqlout.txt , vuelva a cargarlo, luego seleccione todo, elimine todo el texto y luego guarde el archivo ahora vacío. De esa forma, puedo ejecutar la acción que quiero rastrear y luego solo ver los comandos ODBC relevantes sin todos los demás ruidos que no tienen nada que ver con la acción que se está rastreando.
Aquí hay un video rápido para demostrarlo:
Conclusiones
Aprendió cómo activar el rastreo ODBC y ver la salida generada por Access. Puede ver que puede recopilar resultados incluso de acciones como simplemente abrir una tabla o ejecutar una consulta. Eso le brinda información sobre qué tipo de consultas SQL envía realmente Access a la fuente de datos ODBC.
Como puede ver, el rastreo SQL de ODBC captura todos los comandos SQL de ODBC emitidos por Access incluso si no los emitió directamente. Por lo tanto, puede usarlo en cualquier punto en el que experimente ralentizaciones para las que no tenga una buena explicación. Como ejemplo, suponga que tiene un formulario que tarda en abrirse y no está seguro de que sea su código VBA en Open del formulario. o Load eventos o el origen del registro que es el problema. Una estrategia sería configurar la aplicación de Access para que esté a punto de abrir ese formulario, borre el sqlout.txt archivo de texto y luego proceda a abrir el formulario. A continuación, puede revisar las sentencias ODBC SQL rastreadas y determinar si hay alguna que se pueda mejorar.
Eso es particularmente valioso cuando se trata de un formulario o informe complejo que también contiene subformulario/subinformes o contiene cuadros combinados o cuadros de lista que emiten sus propias consultas para satisfacer la propiedad de fuente de fila.
En el próximo artículo, analizaremos el resultado cuando naveguemos por los registros.
¿Necesita ayuda con Microsoft Access? Comuníquese con nuestro equipo al 773-809-5456 o envíenos un correo electrónico a [email protected].
