Ya vimos en el artículo anterior “Microsoft Access y ADO, descubriendo un nuevo escenario para tratar los datos” en el fregao en el que nos estamos metiendo para solicitar información a una base de datos externa íntegramente desde el Visual Basic de nuestro Microsoft Access, pero también hemos dicho que bien dosificado, tal y como estamos haciendo, será mucho más fácil de entender y de hacerlo funcionar sin necesidad de fustigarnos con el látigo.
Ha llegado el momento de empezar a toquetear cosas, así que pongámonos manos a la obra.
Las referencias a librerías dentro de VBA
Access incorpora de serie algunas librerías que son las que nos permiten, desde Visual Basic, interactuar con formularios, botones y demás elementos que posicionemos en pantalla. Sin embargo, al instalar Microsoft Office también se instalan otro montón de librerías con herramientas para trabajar con otros entornos y otras aplicaciones, solo que no estarán activadas por defecto. Es más, en nuestro Windows existen cientos de librerías de otros programas que podemos utilizar, siempre y cuando sepamos cómo utilizarlas. Para el que no tenga muy claro el concepto de librería podríamos definirla como una caja de herramientas específicas. Por ejemplo, piensa en la caja de herramientas de un carpintero, la misma contendrá escofinas, martillo, cepillo, ingletadora, etc. No significa que el hombre vaya a utilizarlas todas pero las lleva encima y, si en un momento dado necesita una de ellas, sólo tiene que sacarla de la caja y utilizarla. Ahora piensa en una caja de herramientas de un fontanero, seguramente lleven algunas herramientas comunes, como un martillo, pero la del fontanero contendrá otras muchas específicas de ese oficio. Nuevamente no tiene por qué utilizarlas todas siempre, pero las lleva encima, por si caso. ¿Tendría sentido que el carpintero llevara siempre consigo, a parte de su caja, otra con las herramientas de un fontanero por si acaso necesita una de ellas? Bueno, el peso que tendría que soportar todo el día con las dos cajas de herramientas no estaría justificado sólo “por si acaso”. Por eso en Access tendremos que activar sólo aquellas librerías que tengamos intención de usar.
Ahora traslademos este símil al Visual Basic de Microsoft Access. En este entorno trabajamos con botones, cuadros de texto, cuadros combinados, imágenes, formularios, etc. Si no tuviéramos una caja de herramientas completita tendríamos que andar fabricándonos a mano, y desde cero, muchas de las cosas que utilizamos, sin embargo, Access usa la librería “Microsoft Access XX.X Object Library”, que ya viene activada por defecto y que incluye en su interior muchísimo código que realiza por nosotros muchas de las tareas cotidianas. Realmente no vemos todo ese código Visual Basic que un programador se ha molestado en desarrollar por nosotros pero si vemos una mínima parte de ese código que nos indica cómo debemos utilizar la herramienta.
Por poner un ejemplo sencillo. Seguro que alguno habrá creado un MsgBox para que aparezca un mensaje en pantalla avisando de algo. La línea de código que lo pone es realmente sencilla:
MsgBox «Acaba de eliminar el registro. Ya no podrá recuperarlo.», vbOKOnly Or vbInformation, «Atención»
Claro, estamos tan acostumbrados a simplificar las cosas que no somos conscientes de que un mensaje en pantalla no se construye sólo con una simple línea con el texto que llevará el mensaje. ¿Dónde definimos el tamaño de la ventana dónde aparece el mensaje? ¿Y el grueso de sus bordes? ¿Y el color de fondo? ¿Y la alineación del texto? Y si lleva un botón de “ACEPTAR” ¿dónde está escrito la posición y el tamaño del botón? ¿Dónde hemos programado que al pulsar el botón “cerrar” la ventana debe cerrarse?
¿A que nunca te has planteado estas preguntas? Todas esas cosas hay que programarlas también, es necesario más código para indicarle al sistema como debe pintar ese mensaje de texto en pantalla, sin embargo, nosotros apenas hemos tenido que escribir una sola línea con el texto que incluirá y el tipo de botón que debe llevar.
¿Quién hace el resto entonces? Pues parte del código que está dentro de la librería “Microsoft Access XX.X Object Library” y que otro programador ha escrito por nosotros. Realmente cuando escribimos “MsgBox” Access sabe que tiene que buscar ese código dentro de la librería y allí, todo eso que no vemos, se encargará de realizar el resto de operaciones por nosotros.
La librería ADO
Creo que más o menos habrá quedado clara la finalidad de una librería. Siendo así volvamos a la causa que nos ocupa en esta serie de artículos.
ADO es una librería que podemos añadir a nuestro fichero de Access. Dentro de ADO hay infinidad de código que nos va a permitir interactuar con bases de datos externas. Si bien, al igual que pasaba con el MsgBox, tendremos que escribir algo de código, el grueso del trabajo lo realizarán las miles de líneas que contiene que se encargarán de procesar el trabajo por nosotros. Y nosotros, como quien dice, con unas pocas órdenes haremos funcionar nuestra aplicación.
Dicho esto, vamos a decirle a Microsoft Access que queremos utilizar la librería ADO:
Herramientas de base de datos -> Visual Basic
Herramientas -> Referencias
Esta ventana, a parte de las cientos de librerías que encontraremos en nuestro sistema, muestra al principio las que ya se están usando en nuestro fichero de Access.
A continuación debemos localizar la librería “Microsoft ActiveX Data Object 6.1 Library” que, abreviando por eso de que el nombre asusta, la llamaremos “ADO”. La seleccionamos y, la próxima vez que abramos esta ventana aparecerá al principio.
¿Y qué pasa con el resto de referencias que se llaman igual? Pues ni más ni menos que son las distintas versiones que han ido saliendo desde que se inventó tan magnífica librería. Como en todo, con los años, y con cada versión de Office, la librería se ha ido mejorando junto con todas las herramientas (trocitos de código) que tiene dentro.
Por mantener compatibilidad con ficheros Access antiguos que se programaron con esas versiones se han dejado en la instalación pero eso no significa que tengamos que usarlas todas. Para mí, y si estás usando la última versión de Office, lo mejor es usar la última versión de la librería, a día de hoy, la 6.1.
Es evidente que, a un número más elevado, más completa y moderna será. Si tienes la oportunidad de abrir un Access de hace 10 años es posible que utilice una versión antigua como la 2.0 o la 2.5 que, si bien seguirán funcionando, no serán capaces de realizar tantas cosas como la última versión.
Y si lo que estás pensando es en marcarlas todas “Por si acaso”, en primer lugar no podrás porque te dirá que dos versiones de la misma librería no pueden convivir juntas en el mismo fichero de Access. Pero tampoco deberías hacer eso con el resto de librerías ya que, añadirla a nuestro fichero Access hará que este ocupe un poquito más por cada una de ellas, pues le estamos añadiendo más información al mismo.
Pues ya sólo nos falta un último paso antes de que Access esté capacitado para pedir información a un servidor. Nos queda instalar un driver ODBC que viene a ser como el traductor entre Access y la base de datos a la que queremos pedirle datos. Hablamos de él en el próximo artículo.
Tengo un problema con la conexión ADO; las librerías Microsoft Activex Data Objects 6.1 library y Microsoft ADO Ext 6.0 for ddl security están cargadas.
Dim miConexion As New Connection
Set miConexion = CurrentProject.Connection
Dim sql As String
sql = «SELECT tbl_forms.int_frmid, tbl_forms.str_frmnom From tbl_forms WHERE (((tbl_forms.str_frmnom)=[frm_nom]))»
Dim miRecordset As Recordset
el error de compilación dice: «El uso de la palabra clave New no es válido».