Relación De Base De Datos

Objetos DAO

ACCESO A BASES DE DATOS SIN UTILIZAR EL CONTROL DATA

En el capítulo anterior hemos visto los controles capaces de acceder a un Base de Datos, enlazados mediante un control Data. Se comenzó a exponer que no es necesario usar un control Data para acceder a leer datos, añadir registros o cambiar su contenido. Y es más. Comenzaremos ahora a ver que el control Data pese a que puede evitarnos gran cantidad de líneas de código, nos hace perder el control respecto al programa. Es normal. El control Data se ha desarrollado para realizar un trabajo muy estándar. Si nuestra aplicación se separa un poco de lo normal, lo mas probable es que necesitemos realizar las operaciones mediante código. Esto no quiere decir que el Data haya que dejarlo en desuso. Será necesario en aquellas aplicaciones en las que se va a usar un control DBGrid, pues como se recordará, mediante el uso de un control Data metemos en memoria RAM todo el contenido de la base de datos relativo al Recordset que hemos creado. El control Data será necesario en aquellas aplicaciones donde utilicemos un DBGrid, un DBList o un DBCombo. Veremos mas adelante que también será necesario cuando queramos guardar imágenes en una Base de Datos.

El control Data también permite consultas más rápidas a la BD. El hecho de guardar el contenido completo del Recordset en la memoria hace que cualquier consulta sea más rápida. Eso sí, estamos empleando mucha más memoria RAM.

Pero en este capítulo vamos a ver como se pueden manejar bases de datos utilizando otros objetos de acceso a datos. Concretamente los objetos DAO.- (Data Access Objet).

Los objetos DAO utilizan el Motor de Bases de Datos Jet de Microsoft y trabajan directamente sobre el fichero que contiene la base de datos. Existen otros objetos de acceso a datos, como ha podido ver en el capítulo anterior, que no trabajan directamente sobre el fichero, sino sobre una conexión ODBC que enlaza con la base de datos. Son los objetos RDO y ADO, cuyo estudio se realizará en capítulos posteriores. Estos últimos tipos son mas modernos, pero no tienen algunas prestaciones que tienen los DAO, debido precisamente a que no trabajan directamente sobre el fichero. Centrémonos sobre los objetos DAO

Estos objetos, pese a que no tienen representación en la interface gráfica, son objetos Visual Basic como los demás, y nos podremos referir a ellos por su nombre como hacíamos con todos los controles. Eso sí, debemos declararlos como se declaran las variables, y siguen siendo válidos los criterios de declaración de variables en cuanto al ámbito de aplicación. Si declaramos un DAO en un procedimiento, no nos podremos referir a él fuera de ese procedimiento. Si queremos que sea válido en toda la aplicación deberemos declararlo en la sección de declaraciones de un módulo, o en la sección de declaraciones de un formulario si fuese suficiente ese ámbito para nuestra aplicación.

La primera sorpresa suele ocurrir a la hora de declarar un objeto. Por ejemplo, para declarar un objeto tipo DataBase debemos hacerlo con la siguiente declaración:

Dim MiBaseDatos As DataBase

Y al ejecutar el programa puede ocurrirle el siguiente error: Error de compilación. No se ha definido el tipo definido por el usuario.

Lo que le está ocurriendo es que su programa no conoce el tipo de variable DataBase. Para que la conozca, debe agregarle una referencia. Vaya a Proyecto | Referencias … de la barra de menú y seleccione Microsoft DAO 3.51 Objet Library Haga click en Aceptar y ya tiene agregada esa referencia a su programa. Agregar una referencia significa que le ha dicho a su programa que puede hacer uso de una colección de DLLs donde podrá encontrar la definición del objeto o la variable que no encuentra. Ahora ya no le dará el error anterior, pues en esa DLL que acaba de agregarle a su programa está la explicación al secreto de lo que es un objeto DataBase.

Verá que hay mas referencias parecidas a Microsoft DAO 3.51. (Las versiones 2.0, 2.1, 2.5/3.5, y si ha instalado Access2000 tendrá la 3.6) Existen tantas versiones distintas como versiones de Access. En realidad esta DLL no es mas que un componente de Access que podemos usar, al igual que lo hace Access, para gestionar una base de datos. Debe elegir la versión mas alta, pero con cuidado. La versión 3.5 corresponde a la versión de Access 97. Cuando cree con su programa una base de datos con esta versión, no podrá abrirla con Access 2.0 No se olvide de la teoría de la compatibilidad de Microsoft, que dice que cualquier versión que Microsoft considere obsoleta no debe reconocer los datos guardados por versiones más modernas del mismo programa. Piense si es posible que alguien que vaya a abrir una base de datos guardada con su aplicación dispone de una versión anterior de Access. Por ejemplo, cuando se está escribiendo este libro, está recién aparecido Access 2000. ¿Cree que es oportuno en estos momentos, en los que todavía se está introduciendo en muchos usuarios Access 97 usar una DLL que nos cree bases de datos que solamente puedan ser abiertas por Access 2000?.

La versión Microsoft DAO 3.6 corresponde a Access 2000. Si ha instalado este programa le aparecerá esa referencia en la lista de referencias. No se sorprenda si antes de instalar Access 2000 no tenía esa referencia y después de la instalación sí. Si crea una BD con la versión 3.6 no podrá abrirla con Access 97 ¡Esta es la compatibilidad hacia delante de Microsoft!

Objetos DAO de acceso a datos

Son muchos y tienen estructura jerárquica. Es importante resaltar lo de su estructura jerárquica, ya que como verá, un objeto DAO crea los objetos DAO inmediatamente inferiores en jerarquía.

Hay que señalar que las colecciones de estos objetos DAO son a su vez objetos de acceso a datos. Esto hay que explicarlo un poco mejor. Por ejemplo, un objeto Database es un objeto DAO que representa una base de datos abierta. Al objeto que agrupa a todas las bases de datos abiertas en ese momento le llamamos Objeto Databases. Si tenemos dos bases de datos abiertas en un determinado momento, el objeto Databases contendrá dos elementos.

Todos los objetos DAO excepto el dbEngine tienen colecciones. Es lógico. El dbEngine, como verá mas adelante, es precisamente el Motor de Bases de Datos Jet y solamente existe uno. Comenzaremos precisamente por él la explicación de los objetos DAO.

El dbEngine es el motor Jet. Y como vimos en el capítulo anterior, la versión 3.5 puede trabajar directamente sobre el fichero de la base de datos o a través de una conexión ODBC. En el primer caso decimos que está trabajando en el espacio de trabajo Microsoft

...