DAO: Writing a Database Application

|  Overview |  How Do I |  FAQ |  Sample |  |  ODBC Driver List

This family of articles discusses writing database applications with the MFC DAO classes. Other articles focus on various parts of the process; this article looks at using DAO from an application design standpoint.

In This Article

This article considers:

• What is a database application?

• First steps in writing your MFC DAO application

• Data viewing choices

• Documents and views with DAO

• DBMS choices

Other Articles in the Article Family on the Process

The following additional articles discuss parts of the design and development process (in recommended reading order):

• DAO: Database Application Design Options

• DAO: Steps in Writing MFC DAO Applications

What Is a Database Application?

Database applications obtain and manipulate data from a database managed by a database management system (DBMS). Typical database applications include programs for data input, data viewing, and batch processing of data.

Of course, there is no one kind of database application. There is a wide range from simple data entry or data viewing applications to complex client/server applications.

Beyond that, applications of any sort might use a database rather than disk-based files for input/output. For example, an e-mail client program that you use to read your mail doesn’t feel like a traditional database application, but it might use a database to store addresses, messages, and other information. In any case, the MFC DAO classes supply abstractions that you can use to write any kind of database application.

First Steps in Writing Your MFC DAO Application

To begin, you must make two fundamental decisions:

• How do you want to display data in your application: in a form, as a list, some other way, or not at all.

• What database management system(s) (DBMSs) do you intend to target?

Your decisions determine how your application fits into MFC's document/view architecture and how appropriate the DAO classes are for your application. Your answers also help determine the selections you make when you run AppWizard to begin constructing your application.

Data Viewing Choices

MFC supplies varying degrees of support for different viewing choices:

• Displaying one record at a time in a form.

  AppWizard will create a -derived class for you and connect it to a based on a table you specify. This makes it easy to create simple form-based applications.

• Displaying multiple records at a time.

  While AppWizard doesn't give any special help for this option, you can fairly easily connect a CDaoRecordset to a or . For examples, see the MFC Database sample .

• Displaying multiple views of the data simultaneously, either in separate windows or in panes of a splitter window.

Documents and Views with DAO

Do you need the MFC document/view architecture? The simplest architecture for MFC applications is to manage your data within an MFC document object and manage displaying that data separately in a view object. You aren't limited to this structure, though. Other options include:

• Using a view object but treating the document as an unused appendage.

  You can make your data structures — mainly your and objects — members of your -derived class rather than of a -derived class. Database applications typically don't need MFC's serialization mechanism, which is the primary feature of CDocument.

  A particularly strong argument for using MFC’s document/view architecture is the ability to manage multiple views of your data through the document. CDocument has an member function that you can call to synchronize your views as data displayed in them changes. This is as useful in database applications as in any other kind of application.

• Drawing your data directly into the client area of a -derived class.

  You can handle Windows messages in the frame window and thus dispense with the view and the document. If you use a view, you can't just strip the document code from your application, but if you use neither view nor document, you can remove (or ignore) both the view code and the document code. In this case, you can store your CDaoDatabase and CDaoRecordset objects in the frame window class.

• Basing your application on a dialog box.

  AppWizard supports this approach, and you can store your object(s) as members of your -derived class.

For related information, see the articles MFC: Using Database Classes with Documents and Views and MFC: Using Database Classes Without Documents and Views.

DBMS Choices

DAO is based on the Microsoft Jet database engine. Thus, DAO is optimally suited for working with Microsoft Jet (.MDB) databases. DAO also supports accessing external databases, including certain installable ISAM databases (which the database engine can read directly) and ODBC data sources. This means you can write DBMS-independent applications with DAO, targeting any data source that the Microsoft Jet database engine can read directly or for which your users will have the appropriate ODBC driver.

Note, however, that in general it is more efficient, with DAO, to attach ODBC data source tables to a Microsoft Jet database than it is to access the external data source directly. If your application is targeted on an external data source such as Microsoft SQL Server or Oracle, you might want to consider using the MFC ODBC classes instead of DAO.

For related information, see the articles Database Topics (DAO) and DAO External: Working with External Data Sources.

See Also   DAO: Where Is..., DAO: Database Tasks, DAO: Database Application Design Options, DAO: Steps in Writing MFC DAO Applications, MFC: Using Database Classes with Documents and Views, MFC: Using Database Classes Without Documents and Views.