Conectar con la base de datos – ADO y DAO

Normalmente, los artículos que escribo para el blog surgen de necesidades que voy teniendo en los desarrollos de aplicaciones en los que estoy metido. Generalmente suele aparecer la necesidad, me informo, me documento, la resuelvo y luego pienso en el artículo. En este caso no es una necesidad la que surge, es una curiosidad.

Me doy cuenta de que me voy haciendo mayor cuando recuerdo mi escritorio de Windows 98 y sobre todo cuando recuerdo mi primer proyecto como programador en una empresa, una aplicación desarrollada en Access 97. En aquellos tiempos, todas las conexiones las hacíamos con DAO (Data Access Object) aunque ya se empezaba a oír que Microsoft estaba introduciendo otro sistema de manejo de bases de datos llamado ADO (ActiveX Data Objects) con el que pretendía sustituir DAO.

Como al final somos animales de costumbres, los cambios nos suelen costar bastante y como de momento no veía una gran mejora en el nuevo método, decidí utilizar la técnica de «mientras funcione…». Pues bien, estamos en 2014 y además de seguir funcionando, parece que a partir de Access 2007, Microsoft ha decidido que la biblioteca predeterminada de acceso a datos sea algo llamado «Microsoft Access Database Engine Object Library» (ACEDAO) que no es más que la nueva versión de «Microsoft DAO 3.6 Object Library».

Durante unos años se comentaba que ADO funcionaba mucho mejor que DAO, sobre todo en ciertos entornos. Comentaban también que DAO dependía del motor de base de datos Access y que la única forma de ejecutar SQL en el origen de datos era especificar que la consulta fuera «PassThrough», que en DAO no es actualizable (solo lectura).

Luego esas opiniones se fueron «suavizando» y la postura más utilizada era que DAO funcionaba correctamente para bases de datos Access pero que para otros entornos (por ejemplo SQL Server) era mejor utilizar ADO. De hecho, esta es la postura que muchos siguen manteniendo (aunque también he oído que lo mejor es alternarlas 2).

Como no me quiero meter en berenjenales y como este es un blog sobre Access, voy a enumerar las características positivas de DAO y a con ello dejar claro que los ejemplos de este blog van a estar siempre con conexiones realizadas mediante este método.

Por qué utilizar DAO con bases de datos MS Access

• El método es el más antiguo y testado, así que es estable y libre de errores.
• Es el método más rápido.
• Es el que mejor interactúa con bases de datos Access.
• Es el que mejor funciona con tablas ODBC vinculadas.
• Es el actual standard de Microsoft
• Y la más importantes, para qué cambiar si nos funciona correctamente?

No quiero darle muchas más vueltas, así que aquí queda mi opinión.

The following two tabs change content below.

• Bio
• Latest Posts

Arkaitz Arteaga

Administrador at Programador de Palo

Llevo más de 10 años programando, sobre todo en Visual Basic y con bases de datos Access. Para mí, VBA y Access siguen siendo herramientas muy potentes. He desarrollado varios proyectos con PHP y MySql. Si sumo las webs que he tenido, probablemente pasaría de 100. Ahora prefiero dedicar todo mi esfuerzo a este blog (aunque sigo manteniendo unas cuantas...). Trabajo en la administración pública (si, soy funcionario), pero he trabajado en pequeñas empresas e incluso en una "grande" de las telecomunicaciones. Ultimamente estoy bastante metido en abrirme nuevos horizontes con C# y .NET. Renovarse o morir!

Latest posts by Arkaitz Arteaga (see all)

• Access: Encriptar contraseñas con SHA-256 utilizando biblioteca de clases .NET con C# - 4 mayo, 2014
• Rendimiento de Access contra backend Access en servidor de archivos remoto. Cuarta parte. - 27 abril, 2014
• Rendimiento de Access contra backend Access en servidor de archivos remoto. Aclaración. - 21 abril, 2014
• Utilizar biblioteca de clases .NET en Access. Tercera aproximación a la Interoperabilidad COM - 14 abril, 2014
• Vincular tablas en Access con Visual Basic - 11 abril, 2014