MFC: Using Database Classes Without Documents and Views

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

Sometimes you might not want to use the framework’s document/view architecture in your database applications. This article explains:

• When you don’t need to use document/view functionality such as document serialization.

• AppWizard options to support applications without serialization and without document-related File menu commands such as New, Open, Save, and Save As.

• How to work with an application that uses a minimal document.

• How to structure an application with no document or view.

When You Don’t Need Documents

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, don’t 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 may be the only one in memory.

If your application doesn’t 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 would like to synchronize all of 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 would omit the document and store any data or data connections in the frame-window object.

AppWizard Options for Documents and Views

If you use AppWizard to create your application, all of the database options produce applications with documents and views. Some of the options provide documents and views that omit unneeded document functionality. Here are the kinds of document/view support for each option.

AppWizard Options for Documents and Views

For a discussion of using the AppWizard options “A database view, without file support” and “Both a database view and file support,” see Applications with Minimal Documents.

For a discussion of writing applications with no document, see Applications with No Document.

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

Applications with Minimal Documents

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

A Document Without File Support

Select the AppWizard database option “A database view without file support” if you don’t need document serialization. The document serves the following useful purposes:

• It’s a convenient place to store a CRecordset or CDaoRecordset.

  This usage parallels ordinary document concepts: the document “stores” the data — or, in this case, a set of records — and the view is a view of the document.

• If your application presents multiple views (such as multiple record views), a document supports coordinating the views.

  If multiple views show the same data, you can use the CDocument::UpdateAllViews member function to coordinate updates to all views when any view changes the data.

You’ll usually use this option for simple form-based applications such as the Enroll tutorial application. AppWizard supports a convenient structure for such applications automatically.

A Document with File Support

Select the AppWizard database option “Both a database view and file support” when you have an alternative use for the document-related File menu commands and document serialization. For the data-access portion of your program, you can use the document in the same way as described in A Document Without File Support. You can use the document’s serialization capability, for example, to read and write a serialized user profile document that stores the user’s preferences or other useful information. For more ideas, see the article Serialization: Serialization vs. Database Input/Output.

AppWizard supports this option, but you must write the code that serializes the document. Store the serialized information in document data members.

Applications with No Document

You might sometimes want to write an application that uses neither documents nor views. Without documents, you store your data (such as a CRecordset or CDaoRecordset 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

If you have a user interface (other than, say, a console command-line interface), your application draws directly into the frame window’s client area rather than into a view. Such an application doesn’t use CRecordView, CDaoRecordView, CFormView, or CDialog for its main user interface (but it will normally use CDialog for ordinary dialogs).

Writing Applications Without Documents

AppWizard doesn’t support creating applications without documents, so you must write your own CWinApp-derived class and, if needed, also create a CFrameWnd or CMDIFrameWnd class. Override CWinApp::InitInstance and declare an application object as

CYourNameApp NEAR theApp;

The framework still supplies the message-map mechanism and many other features.

Database Support Separate from the User Interface

Some applications need either no user interface or only a minimal one. For example, suppose you’re writing:

• An intermediate data-access object that other applications (clients) call for special processing of data between the application and the data source.

• An application that processes data without user intervention, such as an application that moves data from one database format to another, or one that does calculations and performs batch updates.

Because there is no document that owns the CRecordset or CDaoRecordset object, you’ll probably want to store it as an embedded data member in your CWinApp-derived application class. Alternatives include:

• Not keeping a permanent CRecordset or CDaoRecordset object at all. You can pass NULL to your recordset class constructors. In that case, the framework creates a temporary CDatabase or CDaoDatabase object using the information in the recordset’s GetDefaultConnect member function. This is the most likely alternative approach.

• Making the CRecordset or CDaoRecordset object a global variable. This variable should be a pointer to a recordset object that you create dynamically in your CWinApp::InitInstance override. (This avoids attempting to construct the object before the framework is initialized.)

• Using recordset objects as you would within the context of a document or a view. Create recordsets in the member functions of your application or frame-window objects.