ODBC vs. DAO

ODBC vs. DAO

In multe situatii se doreste migrarea aplicatiilor care folosesc clasele MFC ODBC spre clasele MFC DAO. Aceasta sectiune va detalia marea majoritate a diferentelor dintre clasele ODBC si DAO. Cu toate diferentele cunoscute, va fi usoara migrarea aplicatiilor ODBC spre clasele MFC dorite, daca aceasta migrare este dorita.

De ce migrarea aplicatiei din ODBC? Exista un numar de motive pentru care se doreste aceasta migrare spre DAO, dar decizia nu este simpla sau usor de observat. Primul motiv de luat in seama ar fi ca motorul de baze de date Microsoft Jet folosit de DAO poate citi sursa de date ODBC pentru care exista un driver ODBC. Poate fi eficienta folosirea claselor de baze de date ODBC sau apelarea directa a ODBC, dar Microsoft Jet poate citi singur datele de tip ODBC.

Mult mai complexe cazuri apar cand datele exista pe server sau intr-o varietate de servere. In acest caz, decizia de a folosi clasele ODBC sau clasele DAO este una dificila. Daca se doreste constructia de joinuri heterogene (join intre date de diferite formaturi ca SQL Server si Oracle), atunci motorul de baze de date Microsoft Jet va efectua un join mai eficient decat prin fortarea claselor de baze de date ODBC sau prin apelul direct ODBC. Daca se foloseste un driver ODBC care suporta cursoare, cea mai buna alegere poate fi ODBC.

Alegerea poate fi complicata, de aceea cel mai bine este scrierea unui cod de test de performanta al diferitelor metode bazate pe propriile necesita-ti. Aceasta sectiune presupune ca se doreste migrarea dinspre ODBC spre DAO, personal recomand acest lucru, in primul rand datorita utilizarii usoare a Microsoft Access.

Designul originar al claselor MFC ODBC era bazat pe modelul obiectului DAO care era folosit in Microsoft Access si Visual Basic. Asta inseamna ca sunt multe facilitati comune in clasele ODBC si MFC DAO. In general, modelul de programare este acelasi.

Pentru a evidentia cateva similaritati :

-ambele clase ODBC si DAO au obiecte baze de date care folosesc sublegaturile unui sistem de management de baze de date (DBMS).

-ambele au obiecte recordset care reprezinta un set de rezultate returnate de DBMS.

-clasele DAO pentru baze de date si recordseturi au membri aproape identici cu ai claselor ODBC.

-cu ambele seturi de clase, codul pentru returnarea datelor este identic, cu exceptia unor schimbari de nume de obiecte si membri. Schimbarile sunt necesare, dar de obieci procesul este o schimbare de nume direct inainte cand se migreaza dinspre ODBC spre DAO.

De exemplu, in ambele modele procedura de returnare a datelor este de a crea si deschide un obiect baza de date, de a crea si deschide un obiect recordset, si naviga (misca) astfel ca datele sa efectueze o operatie.

Clasele DAO include mai multe obiecte si un set mai bogat de metode, dar voi detalia doar diferentele dintre clase similare si functionalitati.

Probabil, cea mai evidenta diferenta intre clase sunt schimbarile de nume pentru clase similare si functiile globale. Urmatoare lista prezinta schimbarile de nume ale obiectelor, metodelor si functiilor globale asociate cu clasele bazelor de date :

Schimabarile majore ale functionalitatii care pot afecta aplicatia si necesita mai mult decat un simplu nume sunt listate mai jos.

Constantele si macrourile folosite pentru a specifica notiuni ca tip de recordset deschis si optiuni de deschidere a optiunilor sunt de asemenea schimbate.

Cu clasele ODBC MFC are nevoie sa defineasca aceste optiuni cu

ajutorul macrourilor sau cu tipuri enumerative. Cu clasele DAO, DAO furnizeaza definitii ale acestor optiuni intr-un fisier header (DBDAOINT.h). Astfel tipul recordset este un membru enumerat al CRecordset, dar cu DAO el este o constanta . De exemplu, se va folosi snapshot cand se specifica tipul CRecordset in ODBC, dar in DAO se va folosi DB_OPEN_SNAPSHOT cand se specifica in CDaoRecordset.

Tipul predefinit de recordset pentru CRecordset este snapshot in timp ce pentru CDaoRecordset este dynaset.

Clasa ODBC CRecordset are optiune de creare a tipului de recordset forward-only. In clasa CDaoRecordset, forward-only nu este un tip de recordset, ci mai degraba o proprietate a acestor tipuri de recordset.

Un recordset append-only in CRecordset inseamna ca recordset-urile pot fi citite si alipite doar. Cu obiectul CDaoRecordset, optiunea append-only inseamna ca recordset-ul poate fi alipit (si nu citit).

Functiile membru ale claselor ODBC de tranzactii sunt membrii ai CDatabase si actioneaza la nivel de baza de date. In clasele DAO, functiile membru de tranzactii sunt membrii de nivel inalt (CDaoWork space) si astfel implica obiecte multiple de tip CDaoDatabase, impartind acelasi spatiu de lucru (spatiu de tranzactionare).

Clasa de tratare a exceptiilor a fost schimbata. CDBExceptions sunt aruncate in clasele ODBC si CDaoExceptions in clasele DAO.

RFX_Date foloseste obiecte CTime si TIMESTAMP_STRUCT in timp ce DFX_Date foloseste COleDateTime. COleDateTime este apropiat de CTime, dar este bazat pe stilul pe 8 biti al OLE DATE fata de stilul pe 4 biti al time_t astfel putand contine date mai mari.

Snapshoturile DAO (CDaoRecordset) sunt read-only in timp ce ODBC (CRecordset) pot fi modificate depinzand de driverul bibliotecii de cursoare a ODBC. Daca se foloseste biblioteca de cursoare, CRecordset snapshot poate fi modificat. Daca se foloseste oricare din driverele Microsoft din Desktop Driver Pack 3.0 fara biblioteca de cursoare ODBC, CRecordset snapshot este doar read-only.

Acestea sunt principalele diferente intre cele doua tipuri de modele a bazelor de date. Concernul Microsoft incearca prin furnizarea unei ierarhii mai bune (DAO) pastrarea vechilor clienti utilizatori de Microsoft Access si Visual Basic si acapararea de noi clienti prin vanzarea SQL Server si Microsoft Office 97. De altfel, intr-o nota tehnica producatorii Microsoft au precizat ca clasele DAO pot manipula maxim 500 de inregistrari in FoxPro, dar pot manipula date mult mai mari in Access, SQL Server si Oracle 8 Server.