The SQL Server native provider (SQLOLEDB) may return no data for a VARCHAR field that is larger than 255 characters under the following conditions:
The properties for the rowset will create a Fast Forward cursor.
The AutoFetch property (a provider-specific property) has been set to TRUE.
The query contains a VARCHAR field greater than 255 characters in size.
When data is fetched for the row, IRowset->GetData() returns DB_S_ERRORSOCCURED (0x800040eda) and the status of the column is DBSTATUS_E_UNAVAILABLE. Generating a low-level trace through NetMon or "dbcc traceon" commands will show that the data was correctly returned to the client. If the VARCHAR column is 255 characters or less, or if the cursor type is something other than Fast Forward, data will be present in the rowset as expected.
This problem occurs in all versions of the SQL Server native provider versions 2000.80.380.0 (SQL 2000/MDAC 2.6 SP1 release) and earlier.
When a rowset is being returned from a query, the provider builds an in-memory structure that is laid out according to the metadata sent back by SQL Server. Normally, the provider attempts to keep the data in a contiguous structure to make it easier to manage and simplify binding.
When VARCHAR columns are larger than 255 characters, the SQL Server provider uses what is called "out-of-line columns". This means that the data for the column is not kept in-line with other data. Instead, a separate buffer is allocated for the data, and the column information points to the new buffer.
Due to a design flaw in the provider when using the AutoFetch option with Fast Forward cursors, the buffers for the out-of-line columns have not yet been allocated at the time data is being fetched. This leads the provider to believe there is no data for the column, and no data is returned for that column in the rowset.
To resolve this problem, obtain the latest service pack for SQL Server 2000, the latest service pack for MDAC 2.6, or the hotfix referenced below.
For additional information, click the article number below
to view the article in the Microsoft Knowledge Base:
290211
(http://support.microsoft.com/kb/290211/EN-US/
)
INF: How to Obtain the Latest SQL Server 2000 Service Pack
For additional information, click the article number below
to view the article in the Microsoft Knowledge Base:
300635
(http://support.microsoft.com/kb/300635/EN-US/
)
INFO: How to Obtain the Latest MDAC 2.6 Service Pack
Hotfix
The English version of this fix should have the following file attributes or later.
MDAC 2.6
Date Version Size File name
------------------------------------------------------------
07/12/2001 2000.80.307.0 491,584 bytes Sqloledb.dll
07/12/2001 2000.80.307.0 61,440 bytes Sqloledb.rll
01/08/2001 1,652 bytes EULA.txt
MDAC 2.6 SP1
Date Version Size File name
-----------------------------------------------------------
08/15/2001 2000.80.434.0 495,697 bytes Sqloledb.dll
08/15/2001 2000.80.434.0 61,440 bytes Sqloledb.rll
01/08/2001 1,652 bytes EULA.txt
MDAC 2.7
Date Version Size File name
-----------------------------------------------------------
06/11/2002 2000.81.9001.4 450,560 bytes Sqloledb.dll
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in SQL Server 2000 Service Pack 2 and MDAC 2.6 Service Pack 2.
SQL Server 2000 offers the AutoFetch property and Fast Forward cursors as a fast, lightweight means of returning a small resultset to the client with a minimal amount of network traffic. Fast Forward cursors are optimized forward-only, read-only cursors. When the AutoFetch option is also set, SQL Server automatically returns the first row or batch of rows to the client and closes the cursor when the end of the resultset is reached. These optimizations eliminate the network round-trips normally required to request the resultset and close the cursor.
Fast Forward cursors and the AutoFetch option are both documented in the SQL Server 2000 Books Online.
Copy the sample code below into a new Microsoft Visual C++ console application and compile the code. You may need to change the data source name, user id, and password, so that these values refer to valid values for your SQL Server. This code assumes that a table has already been created in the Pubs database using the following syntax: