Database Options in AppWizard

OverviewDetails

This topic describes the MFC database options available in Step 2 of the MFC AppWizard. These options include:

  • None

  • Only include header files

  • A database view, without file support

  • Both a database view and file support

A record view — derived from class (for ODBC) or class (for DAO)— is a form view, based on a dialog template resource, that uses dialog data exchange (DDX) to exchange data between the view’s controls and a -derived object (for ODBC) or a -derived object (for DAO). You can map the form’s controls to data members of a recordset. For more information about record views, see the article Record Views. For more information about recordsets, see the article Recordset (ODBC) or the article DAO Recordset.

No Database Support

AppWizard defaults to this option (“None” in the AppWizard dialog box) and adds no database support to your application.

Only Include Header Files

Choose this option for the minimum database support. AppWizard adds an #include directive for the header file that defines the database classes. The file AFXDB.H (for ODBC) and the file AFXDAO.H (for DAO) are included in STDAFX.H.

Note that if you do choose a database view with AppWizard, you will only be given the single #include that corresponds to your choice of ODBC or DAO. Your application probably won’t need access to both. When you don’t choose a database view, however, AppWizard can’t anticipate which you prefer, so it provides both.

With this support, you can use any of the database classes, related macros and global functions, and other items defined in the appropriate include file. AppWizard creates no database-related classes for you except for a view class and a recordset class if you choose one of the Database View options; you can create what you need later with ClassWizard.

AppWizard no longer explicitly adds libraries to the link line. The libraries are automatically included by special #pragma directives scattered throughout the MFC header files. You don’t need to worry about library names.

A Database View, Without File Support

Choose this option when you want an application with the following characteristics:

  • A view class derived from or rather than .

    This view class makes your application form-based. AppWizard creates an empty dialog template resource to which you must later add dialog controls with the Visual C++ dialog editor.

  • A class derived from or .

    The record view class contains a pointer to a recordset object based on this class. Record view controls are mapped to recordset field data members via dialog data exchange (DDX).

  • No disk-file user interface and serialization.

    A database application usually manages data record-by-record, interacting with the database, rather than managing whole data files.

  • No document-related File-menu commands.

    This option also creates a menu resource whose File menu lacks document-related commands: New, Open, Save, and Save As. Without serialization, you probably don’t need these commands.

Note   Choosing this option makes the application single document interface (SDI). Choosing file support allows either SDI or MDI (multiple document interface).

This option creates a CDocument-derived class. In general, you’ll use this class to store a CRecordset object, or a pointer to one. For more information on how to use this document class, see the article MFC: Using Database Classes Without Documents and Views. The article discusses various document/view configurations, including applications with no document or view.

Both a Database View and File Support

Choose this option when you want an application with the following characteristics:

  • A view class derived from or rather than .

    This view class makes your application form-based. AppWizard creates an empty dialog template resource to which you must later add dialog controls with the Visual C++ dialog editor.

  • A class derived from or .

    The record view class contains a pointer to a recordset object based on this class. Record view controls are mapped to recordset field data members via dialog data exchange (DDX).

  • A disk-file interface in addition to a record view on the database.

    This application opens a disk file in addition to a database. The disk file might store, for example, “style sheet” information, so the user can configure, save, and quickly restore alternative views of the database.

Note   For the last two options, AppWizard binds all columns of the table(s) you select to the recordset. If you don’t want all the columns, you can remove some of them later with ClassWizard. See the article ClassWizard: Binding Recordset Fields to Table Columns.

What do you want to know more about?