Bug #60818 SQLGetData returning wrong value in StrLen_or_IndPtr parameter
Submitted: 9 Apr 2011 17:34 Modified: 28 May 2013 13:16
Reporter: Edward Boggis-Rolfe Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / ODBC Severity:S1 (Critical)
Version:5.01.08.00 OS:Windows (7)
Assigned to: Bogdan Degtyariov CPU Architecture:Any
Tags: SQLGetData StrLen_or_IndPtr wrong

[9 Apr 2011 17:34] Edward Boggis-Rolfe
Description:
Hello I have two problems with SQLGetData using your latest odbc driver.

First it is returning the incorrect amount of data transferred in the StrLen_or_IndPtr parameter.  e.g. data with the phrase "bla bla bla" 11 chars is returned as 4721.
And second it is preventing me from time to time downloading the full amount, I am only getting a truncated amount.
e.g. in the second case it is also returning 4721 characters but the amount is over 5000.

This is occurring when I am doing an SQLExecute followed by an SQLFetchScroll.  Where some columns that are of known length I am using SQLBindCol, and the columns that are large text or blobs I am using SQLGetData.

How to repeat:
I will upload logs shortly

CREATE TABLE `article` (
  `name` varchar(200) NOT NULL DEFAULT '',
  `description` mediumtext NOT NULL,
  `key_words` text NOT NULL,
  `version` int(10) unsigned NOT NULL DEFAULT '0',
  `date` datetime DEFAULT NULL,
  `author_id` int(10) unsigned NOT NULL DEFAULT '0',
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `base_id` int(10) unsigned NOT NULL DEFAULT '0',
  `type` varchar(45) NOT NULL DEFAULT '',
  `sub_type` varchar(45) NOT NULL DEFAULT '',
  `system` tinyint(3) unsigned NOT NULL DEFAULT '1',
  `article_type` char(10) NOT NULL DEFAULT 'article',
  PRIMARY KEY (`id`),
  UNIQUE KEY `named_version` (`name`,`version`)
) ENGINE=InnoDB AUTO_INCREMENT=652 DEFAULT CHARSET=utf8$$

Here are two sample records for testing against:

'Welcome to Galaomeopathy', 'bla bla bla', '', '1', '2006-09-08 20:36:25', '1705', '1', '1', '', '', '1', 'article'
'Welcome to Galaomeopathy', '<font color="#040400"><font face="Arial, sans-serif"><font size="3">Recent years have seen an unprecedented growth of interest in Homoeopathy. This has been a part of the surge of interest in complementary therapies driven by worries about environmental problems such as chemicals in foods and anxieties about the side-effects and failings of many conventional drugs and treatments. People are also dissatisfied with conventional medicine, which fails to treat them as individuals and sees them as a set of clinical conditions instead. In addition patients want their practitioners to take time to listen to them. Homoeopathy is particularly well placed to respond to these desires.</font></font></font>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">More and more people looking for qualified and experience homeopaths. It is not very easy for find a homeopath. Yellow pages won''t give all information on individual homeopath.</font></font></font></p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">We developed this site because there is a real demand for good living database of homeopaths. There are many of homeopathic databases available but none of them will have enough information about practitioners, what the difference between different homeopathic colleges, how to choose a homeopath, what the letter after the name mean, what to expect from homeopathic treatment and why homeopathy is scientific system of medicine. We need to convince general public that it is safe to have homeopathic treatment and that they can trust our expertise. It is very difficult for single homeopathic website to be found in search. Many website with list of homeopaths are out of date. </font></font></font><br />

</p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">This website was build for you. We created it to make it easy for you to manage your own page. Not all homeopaths are familiar with computer, therefor we design the website with you in mind. You can keep your web page up to date yourself without ant knowledge how to write websites and for free. You can also be contacted through the site by your potential patient and can have a chat on-line. </font></font></font></p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">If you are very good with computer and even got your own website, we can put the link to it.</font></font></font><br />

<br />

</p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">This is the only site with living homeopathic database, that we update regularly. You can find the homeopaths in your area and choose which one is more appropriate for you. We also provide some information that will help you to choose the practitioner you require. Our search is easy to operate. </font></font></font><br />

<br />

</p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">Please contact us if you have any questions and suggestions. Your feedback is very valuable for us. </font></font></font><br />

<br />

</p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">We provide a database for patients to find a homeopath.</font></font></font></p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">GH provide services for general public and homeopaths. </font></font></font></p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">GH for general public: sophisticated search for homeopath with explanation about homeopathy, different homeopaths and homeopathic treatment. The luck of knowledge about homeopathy and information about homeopaths prevent general public to use our services </font></font></font></p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">GH for homeopaths: Homeopaths can have there profiles on our site, link to there websites. To make it easy it is possible to write web page on-line.</font></font></font></p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">We would like to have all homeopaths on our database, the only criteria we have that the homeopath is fully qualified and insured. </font></font></font></p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">If you have any interesting information, articles or news please send it to us and we will put it on our site.</font></font></font></p>

<p lang="en-US" style="FONT-STYLE: normal"><font color="#000000"><font face="Arial, sans-serif"><font size="3">Please let us know your opinion about this site and your suggestions how to make this site better. We are working very hard to make GALAHomeopathy site useful for homeopaths.</font></font></font></p>', '', '2', '2006-09-08 22:06:17', '1705', '2', '1', '', '', '1', 'article'

Suggested fix:
Could there be a problem counting the data being retrieved?  Perhaps a misinterpretation of the utf8 character set on windows?
[9 Apr 2011 17:36] Edward Boggis-Rolfe
ODBC trace log file

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

[10 Apr 2011 19:12] Edward Boggis-Rolfe
OK more information, it looks as though buffer (for the bound non blob columns) is getting trashed with data from the unbound blob data.

Secondly the buffer size is not being checked or updated after the first iteration.

The sequence is 
SQLFetchScroll
SQLSetPos 1  //move to first position//different wierd things happen if not called
SQLGetData  4721 characters in record, recieved 4721 characters, reported 4721 in StrLen_or_IndPtr

SQLSetPos 2  //move to next position
SQLGetData  >4721 characters in record, recieved 4721 characters, reported 4721 in StrLen_or_IndPtr //error

SQLSetPos 3  //move to next position
SQLGetData  11 characters in record, recieved 4721 characters (mostly garbage after 11 characters), reported 4721 in StrLen_or_IndPtr //error
[15 Apr 2011 9:24] Bogdan Degtyariov
Edward,

Thank you for reporting the problem in Connector/ODBC driver.
I checked the ODBC trace file you attached, but it looked very much like one of the standard tests from the testing suite, which successfully passed.

Do you have a test case for this bug?
It can be in any language (C/C++ preferable).
With the test case it is much easier to diagnose the problem or spot mistakes in the test itself.
Thanks.
[15 Apr 2011 10:56] Edward Boggis-Rolfe
Hi I will try to, the problem is the code is heavily embedded in something else that I am sure that you do not want to debug.  I will try and get something to you soon.

The thing generally goes haywire in my when you have a mixture of bound columns and unbound text blob columns, so some of the data is automatically connected to an array of data and in others I am having to use SQLGetData, using SQLFetchScroll with more than row to retrieve in each rowset, and using SQLSetPos to go from one row in the row set to the next.  I am doing SQLGetInfo SQL_GETDATA_EXTENSIONS and checking the SQL_GD_BLOCK flag, which is there to confirm that I can do this, but it does not.

Regards

Edward
[16 Jun 2011 4:11] Bogdan Degtyariov
No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you.
[28 May 2013 13:16] Bogdan Degtyariov
I'm closing this bug because I can not continue without feedback from the reporter. If you have new info, please reopen the report.