The information in this article applies to:
BUG #: 16037 (Windows NT, 6.50) SYMPTOMS
If a stored procedure is selected as the victim in a deadlock situation, a
temporary table created within the procedure may become stranded in tempdb.
This situation will only occur if, in addition to the temporary table, a
cursor is declared within the stored procedure, and the stored procedure
then acts upon the temporary table.
Attempts to drop the temporary table prior to re-creating it will fail, and you will receive error message 3701:
The existence of the temporary table can be confirmed by selecting from tempdb.sysobjects for that table. This problem does not occur if a cursor is not used within the stored procedure. Thus, if a cursor is absent, the temporary table is correctly cleaned up from tempdb after a deadlock. WORKAROUNDTo work around this problem, try to close out the connection on which the deadlock occurred, prior to resubmitting the command. It is not necessary to cycle SQL Server in order to clean up an object left stranded in this manner, because that process (and any associated resources) appear to be released once the creating process is closed. STATUSMicrosoft has confirmed this to be a problem in Microsoft SQL Server versions 6.0 and 6.5. This problem has been corrected in U.S. Service Pack 2 for Microsoft SQL Server version 6.5. For more information, contact your primary support provider. MORE INFORMATION
On SQL Server 6.0, the temporary table was not left stranded after a
deadlock. However, an attempt to declare and open the cursor fails, with
the following error message:
This error message is then followed by the following error:
Keywords : kbnetwork SSrvStProc kbbug6.50 kbbug6.00 kbfix6.50.sp2 |
Last Reviewed: April 3, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |