¿Es mejor usar ADO o DAO en Access 2007?

Al crear una nueva base de datos en Access 2007, ¿se deberían usar ADO (objetos de datos ActiveX) o DAO (objetos de acceso a datos)?

Editar: Parte de esta base de datos estará importando datos de hojas de cálculo de Excel 2007.

[Para el registro, el nombre oficial de lo que una vez fue ‘Jet’ es ahora el ‘motor de base de datos de Access’.]

Para ACE (el formato .accdb del motor Access2007) tiene que ser ACEDAO.

Para las características de Jet 4.0 tiene que ser clásico de ADO.

Para las funciones de Jet 3.51 y anteriores, elija ADO o DAO. Los dos tienen ventajas y desventajas. La gran mayoría de la funcionalidad del motor de la base de datos de Access es común a ambos; la funcionalidad mutuamente exclusiva es una franja discutible. Una elección de estilo de vida, tal vez, pero no es gran cosa. El codificador inteligente usa lo mejor de ambos 🙂

He usado ambos un poco y ADO es mi preferencia personal. Es más moderno que DAO, por lo que arquitectónicamente es una mejora: modelo de objeto más plano, ninguno de los problemas de DAO, etc. Más propiedades y métodos e introduce eventos (DAO no tiene ninguno), por ejemplo, para la conexión asincrónica y recuperación de registros. Los conjuntos de registros ADO pueden desconectarse, jerárquicamente y fabricarse, los conjuntos de registros DAO no pueden. Básicamente, tomaron las cosas buenas de DAO y las mejoraron.

DAO no está sin sus puntos fuertes. Para empezar, encontrará más ejemplos de códigos DAO que ADO para Access / Jet.

PD, por alguna razón, gente a la que le gusta DAO realmente no le gusta ADO. Ignora la propaganda. ADO no está en desuso. El ACE tiene un proveedor OLE DB y actualmente es la única forma de usar ACE en 64 bits. ADO.NET no ha sustituido a ADO classic más de lo que VB.NET ha reemplazado a VBA6 en proyectos de Access.

EDITAR: solo para aclarar, “Para las características de Jet 4.0 tiene que ser clásico de ADO”, esto se debe a que DAO 3.6 solo recibió algunas mejoras para las características nuevas de Jet 4.0. Por ejemplo, para el DECIMAL datos DECIMAL no puede especificar escala / precisión. Otras características faltan completamente en DAO. Por ejemplo, ¿puede hacer lo siguiente en Jet 4.0 usando DAO (o ACEDAO en ACE para ese caso)?

 CREATE TABLE Test ( col1 CHAR(4) WITH COMPRESSION DEFAULT '0000' NOT NULL, CHECK (NOT EXISTS ( SELECT T1.col1 FROM Test AS T1 WHERE T1.col1 <> '0000' GROUP BY T1.col1 HAVING COUNT(*) > 1 )) ); 

(sugerencia: columna de texto de ancho fijo compresible con restricción de integridad de datos a nivel de tabla.) No, no puede.

AFAIK: las únicas mejoras para ACEDAO fueron para la nueva funcionalidad de ACE, es decir, no regresaron y completaron los huecos de Jet 4.0 en DAO. ¿Y por qué deberían ellos? Todavía tenemos ADO para tapar los huecos. Mejor que el equipo pasara su tiempo de forma más productiva, como solucionar ese molesto error de ordenación de DECIMAL ; para mí, lo mejor de ACE 😉

DAO es la tecnología recomendada aquí. ADO se ha depreciado mucho y ahora está siendo reemplazado por ADO.net.

DAO no solo es el modelo de objetos de datos nativo y recomendado para usar el acceso MS, sino que continúa mejorando y ahora cuenta con muchas funciones nuevas para compartir. En Access 2007 ahora tenemos soporte para listas de SharePoint. Esto significa que el nuevo modelo de objetos DAO para 2007 permite utilizar una lista de puntos compartidos y visualizarla como una tabla de servidor SQL. Eso significa que puede usar SQL en las listas de SharePoint (de hecho, ni siquiera hay un proveedor oleDB que le permita usar las listas de SharePoint de esta manera, pero con DAO ahora puede hacerlo). No hay nada de este tipo que se haya agregado a ADO. Por lo tanto, las listas de SharePoint desde un punto de vista de acceso (dao) ven estas listas de SharePoint como una tabla estándar.

Además, DAO in access también tiene soporte para lo que llamamos tipos de datos complejos. Esto fue hecho para soportar listas XML desde Sharepoint. Tenga en cuenta que para la próxima versión de acceso (2010) vamos a ver un montón de nuevas características adicionales que se agregarán a DAO (ahora JET se llama ACE).

Entonces, es indudable que DAO es el modelo correcto y bueno para usar. ADO no recibe más mejoras, y ha sido reemplazado por ADO.NET.

Entonces, el futuro pertenece a DAO, y está claro que es ahí donde Microsoft está invirtiendo su dinero en términos de acceso a MS y en términos de actualización. Acceso para trabajar con cosas compartidas.

Access 2007 recibió capacidades multivalor para sus definiciones de campo, y una vez más, esto fue el resultado de mejoras para soportar Sharepoint. Sin embargo, estas características son parte de JET y estas mejoras se pueden utilizar sin compartir. ahora son parte de DAO.


edit: Tal vez amplíe esto un poco, y trate de aclarar qué tenemos aquí con respuestas tan opuestas, puedo asegurarle que al usar Access 2007, es mucho mejor usar DAO.

De dónde proviene la confusión, si mira las referencias de herramientas cuando elige usar el acceso predeterminado 2007 al modelo de objetos de datos, el problema aquí es que ya no se llama DAO. Ahora se llama ACE.

Cuando utiliza DAO en Access 2007 Notará en las referencias de la herramienta, que la referencia no está configurada en DAO 3.6 (esa versión se ha depreciado y tampoco ahora forma parte de la descarga de MDAC). Notará que se llama a la nueva referencia al usar DAO en ms-access:

Microsoft Office 12.0 access motor de base de datos Object Library

Ahora, lo anterior es un poco bocón, pero lo anterior es el correcto para el acceso de referencia 2007 cuando va a usar DAO en lugar de ADO.

En otras palabras, quizás deberíamos llamar a este DAO II.

En otras palabras, este motor de datos continúa mejorando y seguramente verá una versión de 64 bits de este motor para oficina 2010 (oficina 14).

Entonces, la pregunta o confusión se centra en qué término iban a usar cuando nos referimos a usar DAO en acceso 2007. La confusión aquí es de hecho que la documentación e incluso las herramientas -> referencia no lo llaman DAO.

Al final del día en Access 2007, si planea usar DAO, significa que estableció la referencia anterior y no establece una referencia a DAO 3.6. De todos modos, no tiene ningún sentido comenzar a usar ADO ahora cuando se ha depreciado, y el nuevo modelo de objetos DAO para el acceso continúa siendo mejorado e invertido por Microsoft.

Espero que esto ayude a aclarar el confuso aquí. Mientras DAO / JET se está depreciando, la nueva versión de acceso 2007 se basa en la misma base de código, excepto que continúa mejorando. Por lo tanto, el nuevo motor de datos en acceso se puede considerar y llamar el nuevo modelo de objetos DAO.

Actualmente estoy bajo NDA en este tema, pero seguramente puedo decirles que para la próxima versión de la oficina (2010) volveremos a ver una gran cantidad de mejoras.

Por lo tanto, es casi unánime entre los desarrolladores de Access que al desarrollar aplicaciones de acceso y utilizar el motor de datos nativo, la preferencia aquí sea usar el modelo de objetos DAO (pero tenga en cuenta que ya no lo estamos llamando así, lo llamamos ACE).

La respuesta a la pregunta depende de lo que estés haciendo. Si está utilizando Access para trabajar con datos que están en un formato cuya interfaz ADO es más versátil, entonces use ADO. Si está utilizando datos de Jet o está utilizando el motor de la base de datos de Jet para trabajar con otro motor de base de datos (a través de ODBC), entonces DAO es la opción correcta.

Pero esa respuesta supone que estás trabajando desde Access. Si está trabajando desde otro entorno de progtwigción, las respuestas probablemente serán completamente diferentes.

Depende de tus necesidades. No se espera que ninguna herramienta desaparezca pronto.

Si no tiene experiencia en ADO o DAO, encontrará que DAO es mucho, mucho más fácil. A menos que necesite ADO, use DAO.

Usted agregó este elemento crítico: “Estoy tratando de incorporar datos de una fuente externa a un Access DB”. Esta conectividad puede requerir ADO.

ADO es el método de acceso recomendado actual. Creo que DAO ha quedado obsoleto durante bastantes años.

Parece que ha sido desde Access 2000 – según este enlace ,

Lista de tecnologías obsoletas de acceso a datos: http://msdn.microsoft.com/en-us/library/ms810810.aspx#mdac technologies hoja de ruta old_topic9

Cita del artículo anterior, que se revisó en diciembre de 2008 – “Objetos de acceso a datos (DAO): DAO proporciona acceso a las bases de datos JET (Access) .Esta API se puede usar desde Microsoft Visual Basic, Microsoft Visual C ++ y lenguajes de scripting. incluido con Microsoft Office 2000 y Office XP. DAO 3.6 es la versión final de esta tecnología. No estará disponible en el sistema operativo Windows de 64 bits “.

DAO simplemente oscila en términos de rendimiento en comparación con ADO. No hay comparación.

Disculpa que esta es una respuesta, cuando debería haber sido un comentario (no tengo el representante), pero quería aclarar una afirmación errónea de que DAO / ACEDAO no admite el locking de registros Jet 4.0. Sí, y ese es el comportamiento predeterminado, independientemente de lo que afirmen ciertos artículos de MS.

El problema es que esto puede generar una gran saturación (archivo DB muy fragmentado) al usar la edición / actualización de DAO y no se puede desactivar en DAO / ACEDAO.

Si tiene este problema, puede desactivarlo abriendo primero la base de datos a través de una conexión OLEDB utilizando los ajustes correctos de Jet OLEDB: Modo de locking de la base de datos, que le permitirán configurar la base de datos para el locking de nivel de página. Esta propiedad será respetada por las conexiones consiguientes, DAO o de otro modo, para que pueda usar DAO para actualizaciones rápidas, etc.

Esto permitirá que DAO vuelva al rendimiento habitual de 8X en comparación con la ejecución de sentencias de SQL.

Aquí hay un par de enlaces que apuntan al problema:

¿ACEDAO admite el locking de nivel de fila?

http://www.access-programmers.co.uk/forums/showthread.php?t=47040

Artículo de MS KB, incluido el código de configuración del modo de locking con ADO, y luego el uso de DAO en ese DB – http://support.microsoft.com/?id=306435