TN055: Migrar aplicaciones de clase de base de datos ODBC de MFC a clases DAO de MFC

Nota:

DAO se usa con bases de datos de Access y es compatible con Office 2013. DAO 3.6 es la versión final y se considera obsoleta. El entorno y los asistentes de Visual C++ no admiten DAO (aunque se incluyen las clases DAO y todavía se pueden usar). Microsoft recomienda usar plantillas OLE DB o bien ODBC y MFC para proyectos nuevos. Solo debe usar DAO para mantener las aplicaciones existentes.

Información general

En muchas situaciones, puede ser conveniente migrar aplicaciones que usan las clases de base de datos ODBC de MFC a las clases de base de datos DAO de MFC. Esta nota técnica detallará la mayoría de las diferencias entre las clases ODBC y DAO de MFC. Teniendo en cuenta las diferencias, no debe ser demasiado difícil migrar aplicaciones de las clases ODBC a las clases MFC si lo desea.

¿Por qué migrar de ODBC a DAO?

Hay varias razones por las que es posible que desee migrar aplicaciones de las clases de base de datos ODBC a las clases de base de datos DAO, pero la decisión no es necesariamente sencilla o obvia. Algo que hay que tener en cuenta es que el motor de base de datos de Microsoft Jet que usa DAO puede leer cualquier origen de datos ODBC para el que tenga un controlador ODBC. Puede ser más eficaz usar las clases de base de datos ODBC o llamar directamente a ODBC, pero el motor de base de datos de Microsoft Jet puede leer datos ODBC.

Algunos casos sencillos que facilitan la decisión odbc/DAO. Por ejemplo, cuando solo necesita acceso a los datos en un formato que el motor de Microsoft Jet puede leer directamente (formato de Access, formato de Excel, etc.), la opción obvia es usar las clases de base de datos DAO.

Los casos más complejos surgen cuando los datos existen en un servidor o en una variedad de servidores diferentes. En este caso, la decisión de usar las clases de base de datos ODBC o las clases de base de datos DAO es una difícil. Si desea hacer cosas como combinaciones heterogéneas (unir datos de servidores en varios formatos como SQL Server y Oracle), el motor de base de datos de Microsoft Jet realizará la combinación automáticamente en lugar de obligarle a realizar el trabajo necesario si usó las clases de base de datos ODBC o llamó directamente a ODBC. Si usa un controlador ODBC que admite cursores de controlador, la mejor opción puede ser las clases de base de datos ODBC.

La elección puede ser complicada, por lo que es posible que quiera escribir código de ejemplo para probar el rendimiento de varios métodos según sus necesidades especiales. En esta nota técnica se supone que ha tomado la decisión de migrar de las clases de base de datos ODBC a las clases de base de datos DAO.

Similitudes entre las clases de base de datos ODBC y las clases de base de datos DAO de MFC

El diseño original de las clases ODBC de MFC se basaba en el modelo de objetos DAO que se ha usado en Microsoft Access y Microsoft Visual Basic. Esto significa que hay muchas características comunes de las clases ODBC y DAO MFC, que no se mostrarán en esta sección. En general, los modelos de programación son los mismos.

Para resaltar algunas similitudes:

• Las clases ODBC y DAO tienen objetos de base de datos que administran mediante el sistema de administración de bases de datos subyacente (DBMS).

• Ambos tienen objetos recordset que representan un conjunto de resultados devueltos de ese DBMS.

• Los objetos de base de datos y conjunto de registros DAO tienen miembros casi idénticos a las clases ODBC.

• Con ambos conjuntos de clases, el código para recuperar datos es idéntico, excepto en algunos cambios de nombre de objeto y miembro. Se requerirán cambios, pero normalmente el proceso es un cambio de nombre sencillo al cambiar de las clases ODBC a las clases DAO.

Por ejemplo, en ambos modelos, el procedimiento para recuperar datos es crear y abrir un objeto de base de datos, crear y abrir un objeto recordset y navegar (mover) a través de los datos que realizan alguna operación.

Diferencias entre las clases ODBC y DAO MFC

Las clases DAO incluyen más objetos y un conjunto más completo de métodos, pero esta sección solo detallará las diferencias en clases y funcionalidades similares.

Probablemente las diferencias más obvias entre las clases son los cambios de nombre para clases similares y funciones globales. En la lista siguiente se muestran los cambios de nombre de los objetos, métodos y funciones globales asociados a las clases de base de datos:

Clase o función	Equivalente en las clases DAO de MFC
CDatabase	CDaoDatabase
CDatabase::ExecuteSQL	CDaoDatabase::Execute
CRecordset	CDaoRecordset
CRecordset::GetDefaultConnect	CDaoRecordset::GetDefaultDBName
CFieldExchange	CDaoFieldExchange
RFX_Bool	DFX_Bool
RFX_Byte	DFX_Byte
RFX_Int	DFX_Short
RFX_Long	DFX_Long
	DFX_Currency
RFX_Single	DFX_Single
RFX_Double	DFX_Double
RFX_Date1	DFX_Date (COleDateTime-based)
RFX_Text	DFX_Text
RFX_Binary	DFX_Binary
RFX_LongBinary	DFX_LongBinary

¹ La función RFX_Date se basa en CTime y TIMESTAMP_STRUCT.

A continuación se enumeran los principales cambios en la funcionalidad que pueden afectar a la aplicación y que requieren más cambios de nombre simples.

• Se han cambiado las constantes y macros que se usan para especificar elementos como el tipo abierto del conjunto de registros y las opciones de apertura del conjunto de registros.

  Con las clases ODBC MFC necesarias para definir estas opciones a través de macros o tipos enumerados.

  Con las clases DAO, DAO proporciona la definición de estas opciones en un archivo de encabezado (DBDAOINT H). Por lo tanto, el tipo de conjunto de registros es un miembro enumerado de CRecordset, pero con DAO es una constante en su lugar. Por ejemplo, usaría snapshot al especificar el tipo de CRecordset en ODBC, pero DB_OPEN_SNAPSHOT al especificar el tipo de CDaoRecordset.

• El tipo de conjunto de registros predeterminado para CRecordset es snapshot mientras que el tipo de conjunto de registros predeterminado para CDaoRecordset es dynaset (consulte la nota siguiente para ver un problema adicional sobre las instantáneas de clase ODBC).

• La clase CRecordset de ODBC tiene una opción para crear un tipo de conjunto de registros de solo avance. En la clase CDaoRecordset, solo avance no es un tipo de conjunto de registros, sino una propiedad (o opción) de determinados tipos de conjuntos de registros.

• Un conjunto de registros de solo anexión al abrir un objeto CRecordset significaba que los datos del conjunto de registros se podían leer y anexar. Con el objeto CDaoRecordset, la opción de solo anexión significa literalmente que los datos del conjunto de registros solo se pueden anexar (y no leer).

• Las funciones miembro de transacción de las clases ODBC son miembros de CDatabase y actúan en el nivel de base de datos. En las clases DAO, las funciones miembro de transacción son miembros de una clase de nivel superior (CDaoWorkspace) y, por tanto, pueden afectar a varios objetos CDaoDatabase que comparten la misma área de trabajo (espacio de transacciones).

• Se ha cambiado la clase de excepción. CDBExceptions se inician en las clases ODBC y CDaoExceptions en las clases DAO.

• RFX_Date usa objetos CTime y TIMESTAMP_STRUCT mientras DFX_Date usa COleDateTime. COleDateTime es casi idéntico a CTime, pero se basa en una fecha OLE de 8 bytes en lugar de un time_t de 4 bytes para que pueda contener un intervalo de datos mucho mayor.

  Nota:

  Las instantáneas DAO (CDaoRecordset) son de solo lectura, mientras que las instantáneas ODBC (CRecordset) pueden actualizarse según el controlador y el uso de la biblioteca de cursores ODBC. Si usa la biblioteca de cursores, se pueden actualizar las instantáneas CRecordset. Si usa cualquiera de los controladores de Microsoft desde Desktop Driver Pack 3.0 sin la biblioteca de cursores ODBC, las instantáneas CRecordset son de solo lectura. Si usa otro controlador, compruebe la documentación del controlador para ver si las instantáneas (STATIC_CURSORS) son de solo lectura.

Consulte también

Notas técnicas por número
Notas técnicas por categoría