FIX: INSERT EXEC of Extended Stored Procedure Incorrectly Inserts Empty String Instead of NULL

View products that this article applies to.

This article was previously published under Q300258

BUG #: 101698 (sqlbug_70)

Expand all | Collapse all

SYMPTOMS

An INSERT and EXEC statement of an extended stored procedure, which describes a NULL result set column as one of the following Open Data Services (ODS) data types:

SRVCHAR
SRVVARCHAR
SRVBINARY
SRVVARBINARY

is incorrectly inserted into the target table as an empty string. The expected behavior is for the respective column values to be set to NULL.

Back to the top

To resolve this problem, obtain the latest service pack for Microsoft SQL Server 7.0. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

301511 (http://support.microsoft.com/kb/301511/EN-US/ ) INF: How to Obtain the Latest SQL Server 7.0 Service Pack

NOTE: The following hotfix was created prior to Microsoft SQL Server 7.0 Service Pack 4.

The English version of this fix should have the following file attributes or later:

   File name     Platform
   ---------------------- 

   s70997i.exe   Intel

NOTE: Because of file dependencies, the most recent hotfix or feature that contains the preceding files may also contain additional files.

Back to the top

WORKAROUND

Describe the result set columns by using the corresponding SQL Server 7.0 ODS data type:

SRVBIGCHAR
SRVBIGVARCHAR
SRVBIGBINARY
SRVBIGVARBINARY

Note that a column must be described as one of the aforementioned SRVBIG ODS types to take advantage of the SQL Server 7.0 enhancement that widened the maximum length of character and binary (char, varchar, binary and varbinary) types from 255 bytes to 8000 bytes. If a length greater than 255 bytes is specified on the srv_describe or srv_setcollen ODS API calls for columns of type SRVCHAR, SRVVARCHAR, SRVBINARY or SRVVARBINARY, the call will return a FAIL.

Back to the top

STATUS

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 Microsoft SQL Server 7.0 Service Pack 4.

Back to the top