MFC: Using Database Classes with Documents and Views
| Overview | How Do I | FAQ | ODBC Driver List
You can use the MFC database classes ? DAO or ODBC ? with or without the document/view architecture. This article emphasizes working with documents and views. It explains:
How to write a form-based application using a CRecordView or CDaoRecordView object as the main view on your document.
How to use recordset objects in your documents and views.
Other considerations.
For alternatives, see the article MFC: Using Database Classes Without Documents and Views.
Writing a Form-Based Application
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. You can specify CRecordView or CDaoRecordView for your view class when you run AppWizard, or you can use ClassWizard later to create a CRecordView-derived or CDaoRecordview-derived class.
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 AppWizard
- See the article Overview: Creating a Program That Supports a Database.
To add a database form to your application with ClassWizard
- See the article ClassWizard: Creating a Database Form.
For a full discussion of forms, see the article Record Views. For an example of an application with multiple record views on a database, see the MFC tutorial sample , Step 4. Step 4 is not covered in the , but you can examine the code in the sample.
Using Recordsets in Documents and Views
Many simple form-based applications don’t need “documents.” If your application is more complex, you’ll 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 objects in the document. Here are some possibilities for using documents in database applications:
If you’re accessing a recordset in a local context, create CRecordset or CDaoRecordset objects 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’re 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 doesn’t exist yet. Close, delete, and re-create the recordset as needed, or call its Requery member function to refresh the records.
If you’re 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.
Other Factors
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’s a form implemented with CRecordView or CDaoRecordView or something else. As classes derived from CFormView, CRecordView and CDaoRecordView don’t support printing, but you can override the OnPrint member function to allow printing. For more information, see class .
You might not want to use documents and views at all. In that case, see the article MFC: Using Database Classes Without Documents and Views.