FIX: SQL Server 6.5 Service Pack 2 Fixlist (Part 1 of 3) (160731)

SYMPTOMS

When two or more threads share the same database connection (but different hstmts), a call to SQLExecDirect or SQLExecute fails, and one of the following errors occurs:

• [Microsoft][ODBC SQL Server Driver][SQL Server] Received an unrecognized datatype 0 from TDS data stream
• [Microsoft][ODBC SQL Server Driver]Unknown token received from SQL Server
• [Microsoft][ODBC SQL Server Driver]Protocol error in TDS stream

The error(s) received depends on which network library (TCP/IP sockets or named pipes) is being used.

When you use server side cursors, SQL Server Driver invokes the extended stored procedure Sp_cursoropen with incorrect parameters when the following conditions are met:

• The number of parameter markers in the WHERE clause of a SELECT statement are more than one.
• The parameter markers correspond to CHAR or VARCHAR datatypes.
• The network packet size is set to 512 bytes in the server configuration/options.

In addition, SQL Server Driver generates the following error message: The following error message appears if any further activity occurs on the client side: If SQLDescribeCol is called after preparing an outer join statement, it returns the following error: The SQLBindParameter fails after binding a parameter with SQL_C_DEFAULT and SQL_TINYINT under Simplified Chinese Win95. The following error is generated: The following statements demonstrate the problem scenario:

   SQLExecDirect(hstmt, "Create table mytable(id int)", SQL_NTS);
   SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_DEFAULT, SQL_TINYINT,
   1, 0, &sId, 0, &cbId );
   SQLExecDirect(hstmt, "select * from mytable where id=?", SQL_NTS);
				

FIX: Driver Not Capable Error: SQL_COPT_SS_CONNECTION_DEAD

Users who attempt to call SQLGetConnectOption for the Microsoft SQL Server ODBC Driver specific connection option SQL_COPT_SS_CONNECTION_DEAD receive the following error:

FIX: 16-Bit Driver Keyset Cursor Operations with Query Timeout

When you use the client-side SPX Net-Library for Windows (Dbmsspx3.dll), the Microsoft SQL Server 16-bit ODBC Driver version 2.65 may perform significantly slower in operations involving both keyset-driven cursors and the setting of a query timeout. Microsoft has observed a difference up to a factor of six when Dbmsspx3.dll is used, versus the other available net- libraries. Note that for this problem to occur, both a query timeout must be set and keyset-driven cursors must be in use with Dbmsspx3.dll.

FIX: Server Out of Memory when Inserting into Text/Image Fields

Using the 32-bit SQL Server Open Database Connectivity (ODBC) driver to insert chunks of data into text/image columns with the SQLPutData API may cause error 701, "There is insufficient memory to execute the query," from SQL Server 6.5.

When an identity column is added to an existing table using the ALTER TABLE statement, SQLColAttributes and SQLDescribeCol report that the identity column allows NULLS.

If you set up a FOREIGN KEY constraint to reference a table that is populated by replication (that is, a subscribed table), a constraint violation may occur if an UPDATE is run against the published table. This will cause the distribution task to fail with the following error: The NOT FOR REPLICATION option should allow changes submitted by the Distribution task on columns referenced by a FOREIGN KEY constraint from another table that otherwise would violate the constraint.

Any SQLExec task that uses DB-Library can have its query timeout affected by a replication task. Replication tasks use a DB-Library function to globally set the query timeout for the SQLExecutive process, thereby affecting all "DB-Library based" tasks including TSQL, LogReader, SYNC, and Distribution tasks.

Because of this problem, replication tasks may encounter the following message in the Task History: SQLExecutive will automatically retry the replication task, but the task may never run if the query timeout is not long enough.

TSQL tasks may encounter the following error as a Failure: When you use SQL Server replication with the code page 932 installed, some replication commands may not be successfully run, resulting in some Japanese characters being mistakenly replicated in the subscribing table.

FIX: Replicated UPDATE to Char Column May Cause Error 803

LogReader fails with error 803. The errorlog and the task history shows the following message: When you are replicating a table with a text column, and character mode Bulk Copy is used as the mode of synchronization, the SQL Executive service may become unstable. The distribution task is left in a sleeping state, and the SQL Executive service cannot be controlled. The server must be restarted to reactivate the task.

When this problem occurs, the SQL Executive service on the distributor becomes unstable. Also, Enterprise Manager stops responding if you try to click on the running tasks, because the server will not be able to run extended stored procedures related to the SQL Executive service.

Not all tables with a text column will experience this problem. However, tables with a text column are more likely candidates for failure, because the character mode of synchronization is used for such tables by default.

Character mode bulk copy program (BCP) replication synchronization causes a memory leak in SQL Executive.

The amount of memory leaked builds up each time a BCP character mode job is run by the distribution task. Once the system becomes sufficiently low on memory, the distribution task may fail or stop responding. If the task fails, it will return the error "Failed to allocate memory" to the task history. If the distribution task stops responding, it will be listed in the Sysprocesses table as a sleeping process with the command "select * from <table_name>."

Other possible symptoms include SQL Executive unhandled exception errors and other SQL Executive memory allocation failures.