Easysoft ODBC-ODBC Bridge

Why do I get corrupted text columns back from Microsoft SQL Server?

Article:
00982
Last Reviewed:
25th January 2024
Revision:
2

The customer who reported this to us was attempting to retrieve multiple columns defined as SQL Server "text" in PHP . The second text column always contained garbage. This problem only appears to happen when retrieving multiple text fields from a table with SQLGetData and occurs for the second text column retrieved. PHP sees that text fields in SQL Server can be very long so instead of binding the column (as usual) it uses SQLGetData. This problem could occur in any other ODBC interface if SQLGetData is used for multiple text fields.

The specific report involved a table created as follows:

create table BENCH_TEXT (f1 integer, f2 text, f3 text)
insert into BENCH_TEXT values(1, 'some text', 'some text')
select f1, f2, f3 from BENCH_TEXT

The f1 and f2 columns are retrieved OK with SQLGetData, but when the f3 column is requested with SQLGetData, the returned StrLen_or_IndPtr value is usually too short and the data is garbage.

After a search of the net, we discovered a similar report by Chad Slater-Scott which read:

"Subject: BUG: Service Pack 1 on SQL7.0 (SQLExtendedFetch Returns metadata on SQLGetData)

Date: 09/27/1999

Author: Chad Slater-Scott <avacado@usa.net>

Just wanted to let you all know that SP1 For SQL Server has a new bug. After using SQLExtendedFetch or SQLFetchScroll to retrieve records using SQL_ABSOLUTE or SQL_RELATIVE positioning, a SQLGetData call to a text field will return garbage. This is not reproducible if the text field is the only field selected or if you the text field is the first field called. In order to reproduce it, another field value must be retrieved using SQLGetData. I reported this to Microsoft and a Bug has been filed. If any of you are using this sequence of calls and have installed SP1, check your stuff for garbage on the text fields. The Bug ID is 56509 is want to track its status."

We have been told that the problem is in the SQL Server driver included in SP1 for SQL Server and SP6 for NT. The version with the problem appears to be drive:\winnt\system32\sqlsvr32.dll (3.70.06.90) and the working version is 3.70.0623.

Our machines running SQL Server 7 and NT 4 SP4 do not appear to have this problem.

Applies To

Knowledge Base Feedback

* Did this content help you?
* Please select one option based on your first choice:

(* Required Fields)