Easysoft ODBC-ODBC Bridge

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

Article:
00982
Last Reviewed:
27th October 2008
Revision:
2

We have had reported to us a problem accessing text fields in MS SQL Server. The reporter was attempting to retrieve multiple columns defined as SQL Server "text" in PHP and always retrieved garbage in the second text column. 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 f2 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 C:\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 appear OK.

Applies To

Knowledge Base Feedback

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

(* Required Fields)


Oracle is a registered trademark of Oracle Corporation and/or its affiliates.