MySQL Bugs: #16866: Reading twice the field from the same record of the same recset has diff. value

Bug #16866	Reading twice the field from the same record of the same recset has diff. value
Submitted:	28 Jan 2006 11:51	Modified:	4 Apr 2007 4:48
Reporter:	Anestis Fraganestis	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	3.51,5.0	OS:	Windows (Windows XP, Windows 2003)
Assigned to:		CPU Architecture:	Any

Description:
Reading twice the field from the same record of the same recset has diff. value
The problem I have encountered has to do with 'text' fields. I don't know if other types have it also. The first read returns the correct value, while all subsequent reads return an empty string.

How to repeat:
Create table command:
CREATE TABLE `transactions` (
  `TransactionID` int(11) NOT NULL default '0',
  `TransactionValue` float default '0',
  `TransactionDate` int(11) default '0',
  `ReceiptNo` varchar(50) default NULL,
  `CreationDate` int(11) default '0',
  `Description` text,
  `TransactionFrom` int(11) NOT NULL default '0',
  `TransactionTo` int(11) default '0',
  PRIMARY KEY  (`TransactionID`),
  KEY `TransactionDate` (`TransactionDate`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

Versions:
server ver 4.1.8-max
myodbc ver 3.51.12

Program to display the bug:
/************************************************************/
#include "stdafx.h"
#import "C:\Progra~1\Common~1\System\ado\msado27.tlb" \
	rename_namespace("ADO") rename("EOF", "isEOF") rename("BOF", "isBOF")

using namespace ADO;

int _tmain(int argc, _TCHAR* argv[])
{
	CoInitialize(0);
	ADO::_RecordsetPtr X;
	X.CreateInstance(__uuidof(Recordset));
	int loc=X->CursorLocation;
	X->Open(
		bstr_t("Select * from Transactions WHERE TransactionID=134925"),
		CONNECTION_STRING,ADO::adOpenForwardOnly, ADO::adLockPessimistic, ADO::adCmdText);
	bstr_t s1=X->Fields->Item["Description"]->Value;
	bstr_t s2=X->Fields->Item["Description"]->Value;
}
/************************************************************/

the strings s1 and s2 should be equal; instead s2 is empty

Thank you for a problem report. Sorry, but your test case is not complete. Please, add SQL statement to populate table with data and show the results of your program run (you may have to add a couple of printf calls, but anyway) and a makefile or project to build the program. To call something a bug we need a complete and repeatable test case.

Visual C++ 2003 project

Attachment: mysql1.zip (application/zip, text), 69.23 KiB.

Well, I just put 2 entries in the table and then run the programme in debug mode, putting a breakpoint on the line

bstr_t s1=X->Fields->Item["Description"]->Value;

Anyway, if you really think that this would help, here is the SQL for insertion, though it's trivial.

INSERT  INTO `transactions` (`TransactionID`,`Description`) VALUES(134925,'ABC');

INSERT  INTO `transactions` (`TransactionID`,`Description`) VALUES(1,'XYZ');

That should be enough. I've seen the behaviour even with one record only.
As for the project I will upload a zip containing the files, though in order to build it you must change the path of the "import" statement and the connection string.

Well??? Will that do??

Thanks for your test case.  I was able to reproduce this bug with the attached file

bug#27596 marked as a duplicate of this

Due to the fact that 'text' and other long-type fields are read in chunks, they cannot be read twice. This conforms to the ODBC specification (see SQLGetData section). Non-text fields can be read twice via ADO because they are retrieved via bound columns and stored in ADO buffers and not re-read through the driver.

bug#24132 marked as a duplicate of this

bug#26213 marked as a duplicate of this

Does anyone know, if this only apply for cursortype adOpenForwardOnly?

Bug #31029 was marked as duplicate of this bug.

Bug #31553 is marked as duplicate of this bug here.

I'm just going to complete the circle here, because there is a lot of information to be had in other threads about this same bug. Check out this link, and follow the chain of "This bug is a duplicate of..." links that eventually lead back to this post.   https://bugs.mysql.com/bug.php?id=44831