DOCUMENT:Q124321  27-JUL-2001  [odbc]
TITLE   :BUG: SQLGetData Returns SQL_SUCCESS on a Binary Column
PRODUCT :Open Database Connectivity (ODBC)
PROD/VER:WINDOWS:2.0
OPER/SYS:
KEYWORDS:kbBug kbISS

======================================================================
-------------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft Open Database Connectivity, version 2.0 
-------------------------------------------------------------------------------

BUG# QJET: 1780 (2.002317)

SYMPTOMS
========

Under certain conditions when SQLGetData is called on a binary column more than
once, it may return SQL_SUCCESS when it should return SQL_NO_DATA_FOUND. This
happens only for binary, varbinary, or longbinary type of columns.

For example, consider the following sequence of calls which demonstrate the
problem:

      SQLAllocEnv(phenv)
      SQLAllocConnect(henv,phdbc)
      SQLConnect(szDSN,cbDSN,szUID,cbUID,szAuthStr,cbAuthStr)

      SQLAllocStmt(hdbc,phstmt)
      SQLExecDirect(hstmt,"Create table test (col1 longbinary)",SQL_NTS)
      SQLExecDirect(hstmt,"Insert into test values('abc')",SQL_NTS)
      SQLExecDirect(hstmt,"Insert into test values('abcd')",SQL_NTS)
      SQLFreeStmt(hstmt,SQL_CLOSE)

      SQLSetStmtOption(hstmt,SQL_CURSOR_TYPE, SQL_CURSOR_KEYSET_DRIVEN)
      SQLSetStmtOption(hstmt,SQL_ROWSET_SIZE,2)

      SQLExecDirect(hstmt,"Select * from test",SQL_NTS)
      SQLBindCol(hstmt,1,SQL_C_BINARY,rgbValue,cbValueMax,pcbValue)
      SQLExtendedFetch(hstmt,SQL_FETCH_FIRST,1,pcrow,rgfRowStatus)

      SQLGetData(hstmt,1,SQL_C_CHAR,cbValueMax,pcbValue)

This returns SQL_SUCCESS with *rgbValue="616263" and *pcbValue=6. But calling
SQLGetData second time on the same column like:

      SQLGetData(hstmt,1,SQL_C_CHAR,VALID,100,VALID)

Returns SQL_SUCCESS with *rgbValue="" and *pcbValue=0

This should return SQL_NO_DATA_FOUND.

The behavior occurs only if the following conditions apply:

1. The column type is either binary, longbinary, or Varbinary and is bound.

2. The data in the second row is longer than first row.

3. A SQLExtendedFetch with fFetchType as SQL_FETCH_FIRST and SQLGetData
   immediately following the SQLExtendedFetch call.

STATUS
======

Microsoft has confirmed this to be a problem in ODBC Access Driver version
2.00.2317. We are researching this problem and will post new information here in
the Microsoft Knowledge Base as it becomes available.

Additional query words: 2.00.2317 ODBC VISUAL C++ MSVC MFC Windows NT

======================================================================
Keywords          : kbBug kbISS 
Technology        : kbAudDeveloper kbODBCSearch kbODBC200
Version           : WINDOWS:2.0
Issue type        : kbbug

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 2001.