Reading Excel files using ODBC


After contribution that article about writing into an Excel file I got tons of requests about how to read from one. Well, you asked for it…

1) In fact the main problem is that you can’t read an Excel file without previously having some formatting done. Microsoft refers to this in one of their KB papers. If somewhere out there there’s a way to do the reading whithout the formatting, please let me know…

2) Another problem is that DSN you need to have installed in your ODBC Admin. This is not very useful because you don’t always know the name of the Excel file from the start.

3) The last problem I’m dealing with here is generally doing ODBC reading using CRecordset without deriving from it. That is because if I always have to create a class for every single table I want to use, I’ll end up with lots of rather unnecessary code enlarging my app’s exe.


1) According to Microsoft, an Excel sheet of version 4.x and later can only be read by ODBC if a database range is defined. Unfortunately they don’t state how to do this exactly. One way to let ODBC know what data is in there is to name a range of data on a worksheet using “Insert->Names” from Excel’s menu. There can be more than one “table” on a worksheet. This means that a sheet isn’t necessarily the same as a table in a “real” database. If you open “ReadExcel.xls” from the attached demo project and look up the names, you’ll see what I mean…

2) Omiting the DSN tag in the connect string of CDatabase:Open() gives the opportunity to refer the ODBC-Driver directly using its name so we don’t have to have a DSN registered. This, of course, implies that the name of the ODBC-Driver is exactly known. If it isn’t, a call to SQLGetInstalledDrivers() will show all the installed drivers. For an example, see CReadExcelDlg::GetExcelDriver() below.

3) To use CRecordset the plain way you have to use a readonly, foreward only recordset. The data to get is defined by the SQL statement you put into CRecordset.Open(). Reading out the result is done by CRecordset.GetFieldValue(). For an example see the code below.


In order to get the code below going you have to

include <afxdb.h>

include <odbcinst.h>

install an ODBC-driver called “MICROSOFT EXCEL DRIVER (*.XLS)” (or something like that)

Source code

use an ODBC Admin version 3.5 or higher


Using a pseudo DSN only works with ODBC Admin V3.51 and higher. Earlier versions will not be able to use a DSN that actually isn’t installed. The result of an attempt to do so is some mumbling about missing registry keys.

If using an underived CRecordset it needs to be readonly, forward only. So any attempts to change the data or to move back will fail horribly. If you need to do something like that you’re bound to use CRecordset the “usual” way. Another drawback is that the tremendous overhead of CRecordset does in fact make it rather slow. A solution to this would be using the class CSQLDirect contributed by Dave Merner at codeguru’s

There’s still work to do

One unsolved mystery in reading those files is how to get the data WITHOUT having a name defined for it. That means how can the structure of the data be retrieved, how many “tables” are in there, and so on. If you have any idea about that I’d be glad to read it under [email protected] (please make a CC to [email protected])

Source Code

// Query an Excel file
void CReadExcelDlg::OnButton1()
    CDatabase database;
    CString sSql;
    CString sItem1, sItem2;
    CString sDriver;
    CString sDsn;
    CString sFile = "ReadExcel.xls";        // the file name. Could also be something like C:\Sheets\WhatDoIKnow.xls

    // Clear the contents of the listbox

    // Retrieve the name of the Excel driver. This is
    // necessary because Microsoft tends to use language
    // specific names like "Microsoft Excel Driver (*.xls)" versus
    // "Microsoft Excel Treiber (*.xls)"
    sDriver = GetExcelDriver();
    if( sDriver.IsEmpty() )
        // Blast! We didn4t find that driver!
        AfxMessageBox("No Excel ODBC driver found");

    // Create a pseudo DSN including the name of the Driver and the Excel file
    // so we don4t have to have an explicit DSN installed in our ODBC admin

        // Open the database using the former created pseudo DSN

        // Allocate the recordset
        CRecordset recset( &database );

        // Build the SQL string
        // Remember to name a section of data in the Excel sheet using "Insert->Names" to be
        // able to work with the data like you would with a table in a "real" database. There
        // may be more than one table contained in a worksheet.
        sSql = "SELECT field_1, field_2 "
                 "FROM demo_table "
                 "ORDER BY field_1";

        // Execute that query (implicitly by opening the recordset)

        // Browse the result
        while( !recset.IsEOF() )
            // Read the result line

            // Insert result into the list
            m_ctrlList.AddString( sItem1 + " --> "+sItem2 );

            // Skip to the next resultline

        // Close the database

    CATCH(CDBException, e)
        // A database exception occured. Pop out the details...
        AfxMessageBox("Database error: "+e->m_strError);

// Get the name of the Excel-ODBC driver
// Contibuted by Christopher W. Backen - Thanx Christoper
CString CReadExcelDlg::GetExcelDriver()
    char szBuf[2001];
    WORD cbBufMax = 2000;
    WORD cbBufOut;
    char *pszBuf = szBuf;
    CString sDriver;

    // Get the names of the installed drivers ("odbcinst.h" has to be included )
   if(!SQLGetInstalledDrivers(szBuf,cbBufMax,& cbBufOut))
        return "";

    // Search for the driver...
        if( strstr( pszBuf, "Excel" ) != 0 )
            // Found !
            sDriver = CString( pszBuf );
        pszBuf = strchr( pszBuf, '' ) + 1;
    while( pszBuf[1] != '' );

    return sDriver;

Please refer the demo project (ReadExcelDlg.cpp) for more details.

Download demo project – 20 KB

Date Last Updated: May 14, 1999

More by Author

Must Read