MySQL Bugs: #26213: MyODBC ADO String and blob fields are being set to Null After Movefirst call

Bug #26213	MyODBC ADO String and blob fields are being set to Null After Movefirst call
Submitted:	9 Feb 2007 8:12	Modified:	4 May 2007 14:49
Reporter:	Erica Moss	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	Connector / ODBC	Severity:	S1 (Critical)
Version:	5.0.12 (2-07)	OS:	Windows (win xp)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
This problem has come up while running the TestExecuteValidServer() test function from the ADO compaince test rsMoveFirst.vbs.  It is somewhat similar to what was reported in Bug #10628, but unlike that bug, there are no two sequential read operations on any given field, and this problem only occurs in MyODBC 5.0

The script does the following

* Opens a record set to a table with all mysql data types
* picks a random column, and a random row
* calls MoveFirst
Loops over the following:
* reads and stores the random column
* moves to the random row
* calls MoveFirst
* reads and stores the same random column again
* compares the two values

How to repeat:
See ADO compliance test script rsmovefirst.vbs

Either set environment variable "%CONN5%" to the 5.0 connection string, or just hard code it  /common/mysql-common.inc

Pick which connstring to use in mysql-common.inc
Select the version number for myodbcV in mysql-common.inc

Run the script in the Script Unit framework

I neglected to mention the effected MySQL datatypes.  I've only seen this problem occur with  text, mediumtext, longtext, blob, mediumblob, and longblob.  If inside the script you hardcode iTestCol to a column number (0 indexed) that is one of these data types it will fail immediately.

Committed fix for this as rev#801. Please download snapshot and re-run test.

Reverting this patch. It's causing problems with ADO. Researching bug 26164, it seems to be dependent on SQL_NO_DATA.

Duplicate of bug#16866