Throughout the MFC documentation for the MFC DAO classes, you will find references to topics in the DAO SDK documentation, included in the online documentation. Because MFC encapsulates (or wraps) DAO, the MFC documentation:

• Focuses on MFC and how it differs from the underlying DAO implementation.
• Points you to the DAO SDK Help topics for the underlying details. These cross-references are always worded as "topic X in DAO Help."
• Points out differences where MFC does things differently from the way DAO does them. MFC does not wrap all of DAO. For example, MFC does not supply objects for DAO security functionality.

The MFC documentation for the MFC ODBC classes is organized differently. The MFC ODBC classes supply a high-level abstraction that rests on ODBC rather than a wrapper of the ODBC API. Therefore, the two documentation sets are less connected than are the MFC and DAO documentation sets. The ODBC documentation uses the C language, which is much closer to C++ than is Basic.

Many data-access applications are based on forms. The user interface is a form containing controls in which the user examines, enters, or edits data. To make your application form based, use class CRecordView or CDaoRecordView. When you run the MFC Application Wizard and select ODBC client type on the Database Support page, the project uses CRecordView for the view class. The wizards no longer support DAO, so if you want to use CDaoRecordView, you have to code it manually.

In a form-based application, each record view object stores a pointer to a CRecordset or CDaoRecordset object. The framework's record field exchange (RFX) mechanism exchanges data between the recordset and the data source. The dialog data exchange (DDX) mechanism exchanges data between the field data members of the recordset object and the controls on the form. CRecordView or CDaoRecordView also provides default command handler functions for navigating from record to record on the form.

To create a form-based application with the application wizard, see Creating a Forms-Based MFC Application and Database Support, MFC Application Wizard.

For a full discussion of forms, see Record Views.

Many simple form-based applications do not need documents. If your application is more complex, you probably want to use a document as a proxy for the database, storing a CDatabase or CDaoDatabase object that connects to the data source. Form-based applications usually store a pointer to a recordset object in the view. Other kinds of database applications store recordsets and CDatabase or CDaoDatabase object in the document. Here are some possibilities for using documents in database applications:

• If you are accessing a recordset in a local context, create a CRecordset or CDaoRecordset object locally in member functions of the document or the view, as needed.

  Declare a recordset object as a local variable in a function. Pass NULL to the constructor, which causes the framework to create and open a temporary CDatabase or CDaoDatabase object for you. As an alternative, pass a pointer to a CDatabase or CDaoDatabase object. Use the recordset within the function and let it be destroyed automatically when the function exits.

  When you pass NULL to a recordset constructor, the framework uses information returned by the recordset's GetDefaultConnect member function to create a CDatabase or CDaoDatabase object and open it. The wizards implement GetDefaultConnect for you.

• If you are accessing a recordset during the lifetime of your document, embed one or more CRecordset or CDaoRecordset objects in your document.

  Construct the recordset objects either when you initialize the document or as needed. You might write a function that returns a pointer to the recordset if it already exists or constructs and opens the recordset if it does not exist yet. Close, delete, and recreate the recordset as needed, or call its Requery member function to refresh the records.

• If you are accessing a data source during the lifetime of your document, embed a CDatabase or CDaoDatabase object or store a pointer to a CDatabase or CDaoDatabase object in it.

  The CDatabase or CDaoDatabase object manages a connection to your data source. The object is constructed automatically during document construction, and you call its Open member function when you initialize the document. When you construct recordset objects in document member functions, you pass a pointer to the document's CDatabase or CDaoDatabase object. This associates each recordset with its data source. The database object is usually destroyed when the document closes. The recordset objects are typically destroyed when they exit the scope of a function.

Form-based applications often do not have any use for the framework's document serialization mechanism, so you might want to remove, disable, or replace the New and Open commands on the File menu. See the article Serialization: Serialization vs. Database Input/Output.

You might also want to make use of the many user-interface possibilities that the framework can support. For example, you could use multiple CRecordView or CDaoRecordView objects in a splitter window, open multiple recordsets in different multiple document interface (MDI) child windows, and so on.

You might want to implement printing of whatever is in your view, whether it is a form implemented with CRecordView or CDaoRecordView or something else. As classes derived from CFormView, CRecordView and CDaoRecordView do not support printing, but you can override the OnPrint member function to allow printing. For more information, see class CFormView

Some applications have a distinct concept of a document. These applications typically load all or most of a file from storage into memory with a File Open command. They write the updated file back to storage all at once with a File Save or Save As command. What the user sees is a data file.

Some categories of applications, however, do not require a document. Database applications operate in terms of transactions. The application selects records from a database and presents them to the user, often one at a time. What the user sees is usually a single current record, which might be the only one in memory.

If your application does not require a document for storing data, you can dispense with some or all of the framework's document/view architecture. How much you dispense with depends on the approach you prefer. You might:

• Use a minimal document as a place to store a connection to your data source but dispense with normal document features such as serialization. This is useful when you want several views of the data and want to synchronize all the views, updating them all at once and so on.
• Use a frame window, into which you draw directly, rather than using a view. In this case, you omit the document and store any data or data connections in the frame-window object.

The MFC Application Wizard has several options in Select database support, which are listed in the following table. If you use the MFC Application Wizard to create an application, all these options produce applications with documents and views. Some options provide documents and views that omit unneeded document functionality. For more information, see Database Support, MFC Application Wizard.

For a discussion of alternatives to serialization and alternative uses for serialization, see Serialization: Serialization vs. Database Input/Output.

The MFC Application Wizard has two options that support form-based data access applications. Each option creates a CRecordView-derived view class and a document. They differ in what they leave out of the document.

Document Without File Support

Document with File Support

You might sometimes want to write an application that does not use documents or views. Without documents, you store your data (such as a CRecordset object) in your frame-window class or your application class. Any additional requirements depend on whether the application presents a user interface.

Database Support with a User Interface

Writing Applications Without Documents

CYourNameApp theApp;