MySQL Bugs: #27309: MyODBC 3/ ADO conformance test rsmovefirst failing when same col is read twice

Bug #27309	MyODBC 3/ ADO conformance test rsmovefirst failing when same col is read twice
Submitted:	20 Mar 2007 21:48	Modified:	21 Mar 2008 17:29
Reporter:	Erica Moss	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	3.51.14	OS:	Windows (XP sp2)
Assigned to:	Jess Balint	CPU Architecture:	Any

Description:
While running test function TestExecuteValidServer() in the rsmovefirst.vbs script in the ADO level0 conformance tests, the following problem was observed.

The test does the following:
creates a test table
creates a record set based on the full table
reads a random column from the first record
moves forward a random number of records
moves first, and reads the same column read previously
compares the two values and fails if they are different
repeat

This test always fails fairly quickly.  I've found that the stimulus is the situation were the random column chosen for the read happens to be the same column that was read in the previous iteration of the test.  It doesn't always happen the first time the same column is read twice, but it always seems to fail within 1-3 occurances of this situation.  When this occurs, the column read is NULL.

I've placed a workaround for this problem on line 125 to allow the test to be run, and with that in place the test has successfully run 100,000 interations.  Comment this line to reproduce the problem.

How to repeat:
Please see the script in:
/odbc-testing/ado-conformance/trunk/level0/rsmovefirst.vbs/TestExecuteValidServer()

Works fine in both 3.51 and 5.1. EricM, please re-enable this test.

I just commented out the statement that was allowing it to pass, and get the same problem, however I'm now wondering whether it might be my misunderstanding.  The two data types that "fail" are adLongVarChar and adLongVarBinary.

1. The test reads one of these fields from the first record
2. Moves Forward by random amount
3. Moves back to the first record (which I believe triggers a refresh of the recordset) 
4. Reads the same field again, and compares the two 
5. Repeats

What's happening is that if the same field of one of these types is read two times in a row without a MoveFirst refresh then when value read is an empty string.  So the question is, is it appropriate and allowable for the fields of these types to only be able to be read a single time when opened in a forwardOnly cursor?  I'm guessing it probably is.

I've retried this case against SQL Server and even against that data source these two ADO types can only be read a single time unless the cursor is refreshed.  Therefore I will close this issue.