Bug #36012 MyODBC / ADO SQLExtendedFetch error using forward cursors

Description:
Some time after 5.1.2 forward only cursors began throwing errors when updates are attempted.  This seems to occur regardless of data types.

This is the error from the trace:

ScriptUnit      1ea0-1ce4	ENTER SQLExtendedFetch 
		HSTMT               05011A80
		UWORD                        2 <SQL_FETCH_FIRST>
		SQLLEN                     1
		SQLULEN *           0x0012E464
		UWORD *             0x04BC9A08

ScriptUnit      1ea0-1ce4	EXIT  SQLExtendedFetch  with return code -1 (SQL_ERROR)
		HSTMT               05011A80
		UWORD                        2 <SQL_FETCH_FIRST>
		SQLLEN                     1
		SQLULEN *           0x0012E464
		UWORD *             0x04BC9A08

		DIAG [S1106] [MySQL][ODBC 5.1 Driver][mysqld-5.0.45-community-nt]Wrong fetchtype with FORWARD ONLY cursor (537) 

How to repeat:
test case committed to ADO Conformance suite

I was mistaken in the original bug description.  This problem appears to have been present for a while, but it doesn't seem to have any obvious effect on results.  However the error is present in traces when using forward cursors.

Test case added to ADO conformance suite
/tests/bugs/36012.vbs

odbc trace

Attachment: SQL.LOG (application/octet-stream, text), 495.14 KiB.

test is passing for me. can you verify that this is correct?

Xp Vstudio 6 CRecordset::FetcData (::SQLExtendedFetch) fails with 5.01.05.00

Attachment: MySqlFail.txt (text/plain), 1.44 KiB.

XP Sp2 VS6 CRecordset::FetchData fails 5.1.5 on calling:

AFX_ODBC_CALL::SQLExtendedFetch (m_hstmt, wFetchType, nRow, pdwRowsFetched, m_rgRowStatus));

Execution History:

CRecordset::FetchData(unsigned short 1, long 1, unsigned long * 0x0012ec34) line 3049
CRecordset::Move(long 1, unsigned short 1) line 1414 + 27 bytes
CRecordset::MoveNext() line 82 + 60 bytes
CRecordset::Open(unsigned int 4294967295, const char * 0x00000000, unsigned long 0) line 1118
CBalProcSheet::OnSetActive() line 267
CPropertyPage::OnNotify(unsigned int 0, long 1241200, long * 0x0012eda8) line 430 + 14 bytes
CWnd::OnWndMsg(unsigned int 78, unsigned int 0, long 1241200, long * 0x0012edec) line 1620 + 40 bytes
CWnd::WindowProc(unsigned int 78, unsigned int 0, long 1241200) line 1596 + 30 bytes
AfxCallWndProc(CWnd * 0x00c14550 {CBalProcSheet hWnd=0x00070262}, HWND__ * 0x00070262, unsigned int 78, unsigned int 0, long 1241200) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00070262, unsigned int 78, unsigned int 0, long 1241200) line 379
USER32! 7e418734()

Detail:

RETCODE CRecordset::FetchData(UWORD wFetchType, SDWORD nRow,
	DWORD* pdwRowsFetched)
{
	RETCODE nRetCode;

	if (m_nOpenType == forwardOnly && !(m_dwOptions & useExtendedFetch))
	{
		ASSERT(wFetchType == SQL_FETCH_NEXT);

		AFX_ODBC_CALL(::SQLFetch(m_hstmt));
		*pdwRowsFetched = 1;

		m_bDeleted = FALSE;
	}
	else
	{
		AFX_ODBC_CALL(::SQLExtendedFetch(m_hstmt, wFetchType,
/*FAILS HERE!!!  - > */			nRow, pdwRowsFetched, m_rgRowStatus));

		// Set deleted status
		m_bDeleted = GetRowStatus(1) == SQL_ROW_DELETED;
	}

	CheckRowsetError(nRetCode);

	return nRetCode;
}

Jorg,
Please open a new bug report and attach the ODBC trace log.

how can I get patch for this bug?