MFC 2.5 Database Class Frequently Asked Questions

The information in this article applies to:

• The Microsoft Foundation Classes (MFC), included with:

      - Microsoft Visual C++ for Windows, version 1.5
  

SUMMARY

           Microsoft Foundation Class Library, Version 2.5
                           Database Classes
                Frequently Asked Questions and Answers
                     Last revised: April 29, 1994

The text below presents a list of 13 frequently asked questions regarding the Microsoft Foundation Class Library, version 2.5, Database Classes and the answers to these questions. For additional information regarding the Microsoft Foundation Class Library, please refer to the Microsoft Knowledge Base and to the Microsoft Software/Data Library.

The Microsoft Knowledge Base contains technical articles about every Microsoft product.

The Microsoft Software Library contains many complete sample applications. Each file has a corresponding article in the Knowledge Base that describes its purpose. To find information in the Library, first search the Knowledge Base to determine if an appropriate sample is available.

The Visual C++ product also contains extensive MFC documentation in Windows help files. The 'MFC Help' file (MFC.HLP) documents the Microsoft Foundation Classes API. The 'MFC Tech Notes' files (mfcnotes.hlp) contains a collection of technical articles regarding the Microsoft Foundation Classes. The 'MFC Samples Help' file (mfcsamp.hlp) contains information about the sample applications shipped with Visual C++ that use the Microsoft Foundation Classes.

 --------------------------------------------------------------------
| INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT  |
| WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT   |
| NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR    |
| FITNESS FOR A PARTICULAR PURPOSE. The user assumes the entire risk |
| as to the accuracy and the use of this document. This document may |
| be copied and distributed subject to the following conditions: 1)  |
| All text must be copied without modification and all pages must be |
| included and 2) This document may not be distributed for profit.   |
|                                                                    |
| Copyright (C) 1994 Microsoft Corporation. All Rights Reserved.     |
| Microsoft and MS-DOS are registered trademarks and Windows and     |
| Windows NT are trademarks of Microsoft Corporation.                |
 --------------------------------------------------------------------

API: Application Programming Interface DDX: Dialog Data Exchange DLL: Dynamic Link Library MFC: Microsoft Foundation Classes ODBC: Open DataBase Connectivity

********************************************************************* FAQ INDEX TO QUESTIONS: *********************************************************************

The following questions have answers provided within this document. The order of the questions is random and has no significance.

FAQ_1. What problems can be encountered when using AppWizard or

        ClassWizard and a WATCOM SQL ODBC data source?

        after selecting a table in my ODBC text data source while
        using AppWizard to generate my database application?

        -or-

        Why does Windows hang while using AppWizard to generate my
        database application which uses an ODBC text data source?

        -or-

        Why do I get a General Protection Fault (GPF) while
        using AppWizard to generate my database application which
        uses an ODBC text data source?

        data source?

        in my CRecordView with a CTime variable in my CRecordset
        object?

        my application?

        source from my application?

        for my database application grayed out, even after moving
        past the first record?

        -or-

        Why are the menu items "Record.Previous Record",
        "Record.First Record", and "Record.Last Record" grayed out,
        even after moving past the first record?

        -or-

        Why is a database exception being thrown when I call
        CRecordset::MovePrev(), CRecordset::MoveFirst(), or
        CRecordset::MoveLast()?

        -or-

        Why do I see "Internal application error." in a messagebox
        when I call CRecordset::MovePrev(), CRecordset::MoveFirst(),
        or CRecordset::MoveLast()?

        application: "File dbcore.cpp, Line 549, Assertion Failed!"?

        when I try to create a dynaset CRecordset object?

        -or-

        What does it mean when I see "ODBC driver does not support
        dynasets." in the Output window for the Visual Workbench?

        for my query and call CRecordset::Requery(), why do I still
        see the records from the original result set?

        with my database application?

        operation" when I try to use AppWizard to generate a
        database application?

        -or-

        Why does the Visual Workbench hang when I try to use
        AppWizard to generate a database application?

        the Visual Workbench when CDatabase::Open() or
        CRecordset::Open() is called?

     Warning: ODBC Success With Info, Driver's SQLSetConnectOption
              failed
     State:IM006,Native:0,Origin:[Microsoft][ODBC DLL]

     Driver not capable.
     State:IM006,Native:0,Origin:[Microsoft][ODBC DLL]
     State:S1C00,Native:0,Origin:[Microsoft][ODBC Single-Tier Driver]

FAQ_1. What problems can be encountered when using AppWizard or

        ClassWizard and a WATCOM SQL ODBC data source?

• The "Select a table" dialog displays without any tables and then quickly disappears.
• After selecting a table from the list of tables for a WATCOM SQL data source, a messagebox is displayed with the following error:

          SQLGetInfo on SQL_QUALIFIER_NAME_SEPARATOR failed
  
  

• Verify that the ODBC.DLL which comes with VC++ 1.5 is being used rather than the one shipped and installed by WATCOM. Note that, currently, WATCOM SQL version 3.2b has an older ODBC.DLL than Visual C++, version 1.5. This is the cause of the disappearing table list. Future versions of their product may contain newer versions in which case you should not need to use the ODBC.DLL which is supplied with Visual C++. If uncertain about which ODBC.DLL is newer, run the Visual C++ setup again. Select "Custom Installation" and "MFC Database" to tell the setup program to copy over the ODBC.DLL and other drivers. The setup program will only copy over DLLs such as ODBC.DLL if they are newer.
• To avoid the SQLGetInfo error shown above, select two checkboxes, "Microsoft Applications" and "Prevent Driver not Capable Errors", when configuring the WATCOM SQL data source with the ODBC Administrator program.

FAQ_2. Why do I get the message: "SQLColumns failed." immediately

        after selecting a table in my ODBC text data source while
        using AppWizard to generate my database application?

        -or-

        Why does Windows hang while using AppWizard to generate my
        database application which uses an ODBC text data source?

        -or-

        Why do I get a General Protection Fault (GPF) while
        using AppWizard to generate my database application which
        uses an ODBC text data source?

When AppWizard queries for a filename, it incorrectly uses the dot (".") in the filename as a separator between the table owner and the table name. For example, if the file DATASRC.CSV is specified as the initial table, AppWizard will look for a table called CSV, which does not exist. The SQLColumns call is failing because AppWizard is passing an invalid table name by using this technique.

Why is AppWizard incorrectly handling the table name only when using the text ODBC driver? The text ODBC driver accepts text filenames with different extensions for each table. The text ODBC driver, therefore, reports the full filenames for table names. This is in conflict with the ODBC SQL specification, which defines the "." as the table-owner name/table-identifier separator. Other ODBC drivers typically have a very specific filename extension and do not return table names with filename extensions, and therefore there is not a problem with AppWizard incorrectly handling the table name.

FAQ_3. What could be causing problems when I try to use an Oracle

        data source?

Two known problems specific to the Oracle driver are:

• AppWizard and ClassWizard generate an incorrect GetDefaultSQL() function for an Oracle data source table.
• A stack overflow may occur when connecting to an Oracle data source.

   CString CMyRecordSet::GetDefaultSQL()
   {
       return "Dan@Customer";
   }

As mentioned above, an application may also crash because of a stack overflow. The Oracle drivers use a large amount of stack space. If the stack overflows, it will write into the main data segment and cause undefined behavior after returning to the application. If you experience problems when using an Oracle data source, try increasing your application's stack size.

FAQ_4. How do I write a DDX routine to associate an edit control

        in my CRecordView with a CTime variable in my CRecordset
        object?

To support date fields, implement a user-defined DDX routine for CTime objects. A call to this function can be included in the DoDataExchange() method of your CRecordView derived class. A sample implementation of such a function is included with this answer. More information on DDX routines can be found in the MFC Technical Note #26, "DDX and DDV Routines," and in the online documentation for the CDataExchange class.

NOTE: DDX_FieldText is for use with CRecordView derived objects, but the following routine can easily be modified for use with CFormView and CDialog derived classes.

Sample Code

/* Compile options needed:  Default AppWizard MFC Options
*/

/////////////////////////////////////////////////////////////////////
// Example RecordView Data Exchange

#include <ctype.h>

void DDX_FieldText( CDataExchange *pDX, UINT nID, CTime& datevar,
                    CRecordset *pSet );

void CMyRecordView::DoDataExchange(CDataExchange* pDX)

    CRecordView::DoDataExchange(pDX);
    //{{AFX_DATA_MAP(CTranView)

    // ... ( class wizard / app wizard generated code )

    //}}AFX_DATA_MAP

    // date DDX
    DDX_FieldText(pDX, IDC_EDIT_TRAN_DATE,
                  m_pSet->m_Database_Date, m_pSet);
}

/////////////////////////////////////////////////////////////////////
// Example Date DDX_FieldText function

void DDX_FieldText( CDataExchange *pDX, UINT nID, CTime& datevar,
                    CRecordset *pSet )
{
    if ( pDX->m_bSaveAndValidate )
    {
            // Move date from edit control to CTime
        CString strDate;
        pDX->PrepareEditCtrl( nID );
        pDX->m_pDlgWnd->GetDlgItem( nID )->GetWindowText( strDate );
        int nMonth, nDay, nYear;
        int nLen = strDate.GetLength();

        // Parse the date string for mm/dd/yy format.
        BOOL status = FALSE;
        while ( !status )
        {
            int i = 0;
            int nMarker = 0;

            // Note that sscanf() could be used to read
            // these formated strings.

            // find first slash
            while( i < nLen && strDate[i++] != '/' );
            if ( i == nLen )
                break;

            // month
            nMonth = atoi( strDate.Left( i ) );
            if ( nMonth < 1 || nMonth > 12 )
                break;

            // find next slash
            nMarker = i++;
            while( i < nLen && strDate[i++] != '/' );
            if ( i == nLen )
                break;

            // day
            nDay = atoi( strDate.Mid( nMarker, i - nMarker ) );
            if ( nDay < 1 || nDay > 31 )
                break;

            // year
            if ( nLen - i < 2 || ! isdigit( (int) strDate[i] )
                 || ! isdigit( (int) strDate[i+1] ) )
                break;
            nYear = atoi( strDate.Right( nLen - i ) );
            nYear += ( nYear < 37 ? 2000 : 1900 );
            // valid years for CTime object
            if ( nYear < 1970 || nYear > 2036 )
                break;

            CTime tTemp( nYear, nMonth, nDay, 0, 0, 0 );
            datevar = tTemp;
            status = TRUE;
        }

        if ( !status )
        {
            AfxMessageBox( "Incorrect date field format",
                    MB_OK | MB_ICONEXCLAMATION );
            pDX->Fail();
        }
    }
    else
    {
            // Move date from CTime to edit control
        // NOTE: no internationalization: mm/dd/yy format only

        CString strDate = datevar.Format( "%m/%d/%y" );
        pDX->m_pDlgWnd->GetDlgItem( nID )->SetWindowText( strDate );
    }

FAQ_5. How can I programmatically configure ODBC data sources from

        my application?

The ODBC Administrator program creates a new data source by adding entries to the ODBC.INI file. This file is queried by the ODBC Driver Manager to obtain the required information about each data source. It is important to know what information needs to be placed in the ODBC.INI because you will need to supply it with the call to SQLConfigDataSource().

Although this information could be written directly to the ODBC.INI file, without using SQLConfigDataSource(), any application that does so is relying on the current technique that the Driver Manager uses to maintain its data. If a later revision to the ODBC Driver Manager implements record keeping for data sources in a different way, then any application that manually modified the ODBC.INI file instead of calling DQLConfigDataSource() would be broken. It is generally advisable to use an API function when one is provided.

The following example uses SQLConfigDataSource() to create a new Excel data source called "New Excel Data Source":

   SQLConfigDataSource(NULL,ODBC_ADD_DSN,
     (LPSTR) "Excel Files (*.xls)",
     (LPSTR) "DSN=New Excel Data Source\0"
     "Description=New Excel Data Source\0"
     "FileType=Excel\0"
     "DataDirectory=C:\\EXCELDIR\0"
     "MaxScanRows=20\0");

The information below discusses the parameters that need to be passed to SQLConfigDataSource(). To use the SQLConfigDataSource() function, you must include the ODBCINST.H header file and use the ODBCINST.LIB import library. Much of this information is taken from the ODBC API Programmer's Reference supplied with Visual C++, version 1.5.

   Function prototype:

   BOOL SQLConfigDataSource(HWND hwndParent, UINT fRequest,
                            LPCSTR lpszDriver,
                            LPCSTR lpszAttributes);

   hwndParent - This is the window that will be used as the
     owner of any dialog boxes which are created by either the
     Driver Manager or the specific ODBC Driver to obtain
     additional information from the user about the new data
     source. If there is not enough information provided in the
     lpszAttributes parameter, a dialog box will appear.
     This parameter may be NULL, see the reference for specifics.

   lpszDriver - Driver description. As the documentation mentions,
      this is the name presented to the users rather than the
      physical driver (the DLL). You can determine the description
      of a driver using the ODBC Administrator program as follows:

      1. Run the ODBC Administrator program.
      2. Choose Add. This will give you a list of installed drivers.

      The list contains driver descriptions. It is this description
      that you will use as the lpszDriver parameter. Note that the
      ENTIRE description is used [for example, "Excel Files (*.xls)"]
      including the file extension and parentheses if they exist
      in the description.

      Optionally, you can examine the file ODBCINST.INI, which
      contains a list of all driver entries and descriptions
      in the section [ODBC Drivers].

   lpszAttributes - List of attributes in the form "keyname=value".
      These strings are separated by null terminators with two
      consecutive null terminators at the end of the list.
      These attributes will primarily be default driver-specific
      entries, which go into the ODBC.INI file for the new data
      source. One important key, which is not mentioned in the
      ODBC API reference for this function, is "DSN" which
      specifies the name of the new data source. The rest
      of the entries are specific to the driver for the new data
      source. Often times it is not necessary to supply ALL of the
      entries because the driver can prompt the user (if hwndParent
      is not NULL) with dialog boxes for the new values. You might
      want to explicitly supply default values so that the user is
      not prompted.
      One way to find the keynames and their values is to examine the
      ODBC.INI file for an already configured data source (perhaps one
      that has been configured by the ODBC Administrator program):

      1. Open the ODBC.INI file.
      2. Find the section marked by [<data source name>] where <data
         source name> is a data source that has already been
         configured with the desired settings for the driver you
         intend to use. The lines following this line will be of the
         form "keyname=value". These are exactly the entries you will
         want to use in your lpszAttributes parameter.

FAQ_6. How can I programmatically create a table for a data

        source from my application?

MFC version 2.5 uses the ODBC API functions to access and manipulate data. Before a table can be created, ODBC requires that a "data source" be configured to allow access to data. A data source is a label by which information may be retrieved without regard to how, or by whom, the information is managed. The information in a data source is typically managed by one of a variety of ODBC driver programs such as FoxPro, Access, or SQL Server. The information in a data source may be stored in various locations such as locally or on a network. Once a data source is configured/named, the programmer need only specify the name of the data source to connect to the data.

The ODBC Administrator program (typically installed in the Windows Control Panel) may be used to create a data source. Many data sources, for example: FoxPro, maintain a directory specification for databases. That is, a directory *is* the data source and each table within the data source is stored in a separate file within that directory (in the case of dBASE or FoxPro, each table is a .DBF file).

Other ODBC driver programs, such as Microsoft Access and SQL Server, require that some specific criteria be satisfied before a data source can be established. For example, when using the SQL Server ODBC driver you would need to have established a SQL server. The Microsoft Access ODBC driver requires that an .MDB file must exist before it can create a data source. When creating an Access ODBC data source through the ODBC Administrator program, you are given two choices: you can select an .MDB file or you can create an .MDB file. There is not a programmatic way of creating the .MDB file from your application. Therefore, if your application requires that you place data into an Access data source (.MDB file), you most likely will want to have an empty .MDB file that you can use or copy whenever you need it.

Once you have the data source established, creation of tables can be easily performed by using the CDatabase::ExecuteSQL() function and the

'CREATE TABLE' SQL statement. For example, if you had a database

    myDB.ExecuteSQL("CREATE TABLE OFFICES (OfficeID TEXT(10)"
                    ", OfficeName TEXT(10))")

NOTE: The field types specified in the 'CREATE TABLE' SQL statement may vary according to the ODBC driver that you are using. For example, the Btrieve ODBC driver will require "STRING" in place of the "TEXT" type shown in the 'CREATE TABLE' statement above. The MSQUERY program is one way to discover what field types are available for a data source. In MSQUERY, select File, choose Table_Definition, select a table from a data source, and look at the type shown in the "Type" combo box.

For more information about data sources, see the "Database Classes Encyclopedia" in the online books.

FAQ_7. Why are the Previous, First, and Last buttons on the toolbar

        for my database application grayed out, even after moving
        past the first record?

        -or-

        Why are the menu items "Record.Previous Record",
        "Record.First Record", and "Record.Last Record" grayed out,
        even after moving past the first record?

        -or-

        Why is a database exception being thrown when I call
        CRecordset::MovePrev(), CRecordset::MoveFirst(), or
        CRecordset::MoveLast()?

        -or-

        Why do I see "Internal application error." in a messagebox
        when I call CRecordset::MovePrev(), CRecordset::MoveFirst(),
        or CRecordset::MoveLast()?

There are two reasons why the cursor library (ODBCCURS.DLL) might not be loaded:

• An older version of ODBC.DLL than that which is shipped with Visual C++, version 1.5 is used.
• The ODBCCURS.DLL file cannot be found. This DLL should be located in the \WINDOWS\SYSTEM directory. If the ODBCCURS.DLL is missing, you will see the following message in the Output window when running the application with the debugger when MFC DB Tracing is enabled:

        Cursor library not used. Load failed
        State:IM006,Native:0,Origin:[Microsoft][ODBC DLL]
        State:S1C00,Native:0,Origin:[Microsoft][ODBC Single-Tier Driver]
        State:01000,Native:0,Origin:[Microsoft][ODBC DLL]
  

NOTE: To be absolutely sure you have correct versions of the ODBC DLLs, you should run the Visual C++ Setup program again and select "Custom Installation." Then, select only the "MFC Database (ODBC)" check box so that you copy only the needed ODBC components. You will also want to select the ODBC drivers you need by clicking the Drivers button next to the "MFC Database (ODBC)" check box. The setup program only installs files which are of a later version than those that already exist on the system.

FAQ_8. Why do I get the following Assertion when I run my database

        application: "File dbcore.cpp, Line 549, Assertion Failed!"?

   File dbcore.cpp, Line 549, Assertion Failed!

This problem occurs even though CDatabase::CommitTrans() was called after the first CDatabase::BeginTrans() call.

The CDatabase class uses a variable called "m_bTransactionPending" for debug mode, which gets set to TRUE in CDatabase::BeginTrans() with the following code:

   #ifdef _DEBUG
       m_bTransactionPending = TRUE;
   #endif // _DEBUG

   #ifdef DEBUG
       m_bTransactionPending = FALSE;
   #endif // DEBUG

Modify the code in CommitTrans() by changing the DEBUG constant to _DEBUG, and rebuild the MFC library by following the directions in the README.TXT located in the \MSVC\MFC\SRC directory.

As an alternative, you could copy the code from CommitTrans() into a new member function of a CDatabase derived class, fix the code, and call the new function instead of CommitTrans(). However, if you are letting CRecordset create the database object (that is, not passing a pointer to a CDatabase object into the constructor), CDatabase will be used instead of your CDatabase derived class.

FAQ_9. Why do I see "Internal application error." in a messagebox

        when I try to create a dynaset CRecordset object?

        -or-

        What does it mean when I see "ODBC driver does not support
        dynasets." in the Output window for the Visual Workbench?

To use the dynaset attribute of a CRecordset object, you must acquire an ODBC driver that will support the features of a dynaset. MFC Technical Note 42 "ODBC Driver Developer Recommendations" lists the requirements for an ODBC driver if it is to be used for creating dynaset CRecordsets. They are:

   SQLGetInfo, SQL_ODBC_VER must return > "01".
   SQLGetInfo, SQL_SCROLL_OPTIONS must support SQL_SO_KEYSET_DRIVEN.
   SQLGetInfo, SQL_ROW_UPDATES must return "Y".
   SQLGetInfo, SQL_POSITIONED_UPDATES must support
               SQL_PS_POSITIONED_DELETE and
               SQL_PS_POSITIONED_UPDATE.

The information below comes from the README.WRI file included with Visual C++, version 1.5, and discusses what needs to be done to enable dynaset support when using an ODBC driver that meets the requirements shown above.

   CDatabase::Open() forces loading of ODBC's cursor library with
   the ::SQLSetConnection() SQL_ODBC_CURSORS call in dbcore.cpp,
   line 238. Forced loading of the cursor library ensures the
   SQL_SCROLL_STATIC scroll option is supported for snapshots, even
   if the underlying driver does not support scrolling.

   In order to open a recordset as a dynaset, the driver must support
   SQL_SCROLL_KEYSET, and the forced loading of the cursor library
   must be changed to optional loading. This can be done by changing
   the scroll option argument in the ::SQLSetConnection() call
   mentioned above from SQL_CUR_USE_ODBC to SQL_CUR_USE_IF_NEEDED.
   This will cause the cursor library to NOT be loaded if the
   underlying driver supports SQLExtendedFetch(). Note that snapshots
   require either the cursor library to be loaded, or for the
   underlying driver to support SQL_SCROLL_STATIC.

        for my query and call CRecordset::Requery(), why do I still
        see the records from the original result set?

   For either a dynaset or a snapshot, call Requery() any time you
   want to rebuild the recordset using a new filter or sort, or new
   parameter values. Set the new filter or sort property by assigning
   new values to m_strFilter and m_strSort before calling Requery().
   Set new parameters by assigning new values to parameter data
   members before calling Requery(). If the filter and sort strings
   are unchanged, you can reuse the query, which improves performance.

Below is the code for the CRecordset::Requery() function:

   BOOL CRecordset::Requery()
   {
       RETCODE nRetCode;

       ASSERT_VALID(this);
       ASSERT(IsOpen());
       // Cannot requery until all pending Async operations have
       // completed.
       ASSERT(!m_pDatabase->InWaitForDataSource());

       TRY
       {
           // Shut down current query.
           AFX_SQL_SYNC(::SQLFreeStmt(m_hstmt, SQL_CLOSE));

           // Now try to reexecute the SQL query.
           AFX_SQL_ASYNC(this, ::SQLExecute(m_hstmt));
           if (!Check(nRetCode))
               ThrowDBException(nRetCode);

           m_nFieldsBound = 0;
           InitRecord();
       }
       CATCH_ALL(e)
       {
           Close();
           THROW_LAST();
       }
       END_CATCH_ALL

       return TRUE;    // all set
   }

For example, suppose that you have the following SQL statement, which is used for an SQLPrepare() call:

   SELECT name, phonenum from customertable where name = ?

In the SELECT line above, the parameterized filter would be handled by assigning m_strFilter = "name=?", and then using a variable to store the data for the parameter. For more information, see the section titled "Filtering and Parameterizing the Recordset" in "Database Classes", "Part 1: Database Tutorial", Chapter 4 "Step 2: Using a Second Recordset" of the Visual C++, version 1.5 Books Online.

See "Part 1: Database Tutorial" in the "Database Classes" reference and the "ODBC API Programmer's Reference" in the Visual C++, version 1.5 Books Online for more information about ODBC SQL statement parameters, SQLPrepare() and SQLExecute().

Because SQL parameters (for example, ? markers) are not permitted in SORT clauses, you cannot use the Requery() function if you need to change the sorting order.

In summary, if the structure of the SQL statement is not going to change, use ODBC SQL parameters. If the structure of the SELECT statement is changed in the program, you must requery by calling Close() and then Open() for the CRecordset.

Here is an example of a SELECT statement that changes structure during a program. Suppose the original query for the CRecordset is:

   Select name, phonenum from customertable where name = 'Dan'

   Select name, phonenum from customertable where name = 'Dan' and
       zipcode=97439

FAQ_11. How do I figure out what which system files I need to ship

        with my database application?

To find a list of which drivers to ship for a particular type of data source (that is, Microsoft FoxPro, Microsoft Access, and so forth), use one of the following methods:

Method 1

1. Run the ODBC Administrator program (usually in the Control Panel or the Microsoft ODBC Group of Program Manager).

2. Highlight your data source by single-clicking it.

3. Single-click the Setup button to view the Setup dialog box.

4. Single-click the Help button to view the driver help file for that data source.

5. Single-click the Contents button near the top-left corner to navigate to the main Help panel.

6. Single-click "Overview" (the highlighted hyperlink) to view all of the associated files (.DLLs).

Method 2

1. Use File Manager to list the DRV*.HLP files in the \MSVC\REDIST subdirectory on the Visual C++ CD (which may also have been installed to the \WINDOWS\SYSTEM or WINNT\SYSTEM subdirectory of your machine).

2. Run the help file viewer by double-clicking the help file for the driver you are interested in. For example, the help file for the Microsoft Access ODBC driver is called DRVACCSS.HLP.

3. Single-click the "Overview" hyperlink to view all of the associated files (.DLLs).

FAQ_12. Why do I get the message: "Not enough memory to complete

        operation" when I try to use AppWizard to generate a
        database application?

        -or-

        Why does the Visual Workbench hang when I try to use
        AppWizard to generate a database application?

   Not enough memory to complete operation.

The workaround for this problem is to use AppWizard to generate a "database enabled" application. This is accomplished by using another table within the same data source as the table with many columns. However, this other table, henceforth referred to as the "proxy," does not cause AppWizard to fail when generating the application. After the application has been successfully generated, ClassWizard is then used to modify the code to use the table with many columns instead of the proxy. One other change also requires the modification of a single line of code.

The following is a step-by-step approach to using this technique:

1. Identify another table, the proxy, which contains fewer columns in the same data source, or create one.

2. Using AppWizard, create a skeleton application selecting all of the originally desired options. When choosing the data source, use the proxy table identified in step 1.

3. Open ClassWizard (CTRL+W) and switch to the "Member Variables" tab.

4. For the "Class Name," select the CRecordset derived class (it should be a name that ends with "Set").

5. Delete the CRecordset member variables associated with each of the column names in the proxy table. Do this for every member variable by selecting a "Column Name" and clicking "Delete Variable."

6. Now click "Update Columns." Choose "Yes" when prompted to save current changes.

7. Select the data source that has been used during this process and choose OK.

8. Select the table with the large number of columns and choose OK.

9. Click "Bind All" to add variables for all of the columns in the new table.

10. Choose OK to leave ClassWizard.

11. Edit the implementation file (.CPP) for the CRecordset derived class (the filename should be of the form xxxxSET.CPP).

12. Change the "GetDefaultSQL" for the CRecordset derived class provided by AppWizard. Change the code to read

    return "XXXXX";

    where XXXXX is the name of the table with many columns.

13. Save changes by choosing Save from the File menu.

FAQ_13. Why do I see the following messages in the Output window for

        the Visual Workbench when CDatabase::Open() or
        CRecordset::Open() is called?

     Warning: ODBC Success With Info, Driver's SQLSetConnectOption
              failed
     State:IM006,Native:0,Origin:[Microsoft][ODBC DLL]

     Driver not capable.
     State:IM006,Native:0,Origin:[Microsoft][ODBC DLL]
     State:S1C00,Native:0,Origin:[Microsoft][ODBC Single-Tier Driver]

The CDatabase::AllocConnect() function, located in DBCORE.CPP of the MFC sources, contains the following line of code:

   AFX_SQL_SYNC(::SQLSetConnectOption(m_hdbc, SQL_LOGIN_TIMEOUT,
         m_dwLoginTimeout));

These are harmless warnings (that is, connecting was successful) and can be ignored. When you see the warnings, keep in mind that the login time-out has no affect on the data source.