BUG: SQL Breakpoint Not Hit After Executing SP in Another DBLast reviewed: May 21, 1997Article ID: Q165420 |
The information in this article applies to:
SYMPTOMSThe SQL Debugger may fail to stop at breakpoints that are set after a call to a stored procedure from a database (other than the current one) is executed.
CAUSEThe call to the stored procedure in the secondary database changes the context of SQL Server to that database. The SQL Debugger cannot find breakpoints that were set in the context of the previous database and fails to break on them.
RESOLUTIONWork around this by placing a call to a stored procedure that resides in the same database as the stored procedure you were initially debugging.
STATUSMicrosoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this bug and will post new information here in the Microsoft Knowledge Base as it becomes available.
REFERENCES
Sample Code
/* Sample SP which shows the problem */ Create Procedure sp_MySP As SELECT * FROM employee /* Breakpoints set after this call will not be hit */ EXEC OtherDB.dbo.sp_SomeSP SELECT * FROM Authors RETURN (0) ----------- /* Sample SP with a workaround */ /* Add one line of code */ Create Procedure sp_MySP As SELECT * FROM EMPLOYEE EXEC OtherDB.dbo.sp_SomeSP /* This causes the database context to be changed back to original */ /* Breakpoints will now be hit */ EXEC sp_MySP2 SELECT * FROM Authors RETURN (0) /* Stored procedure called from above */ Create Procedure sp_MySP2 As RETURN (0) |
Keywords : kbprg vcbuglist500 VCEntIss VCEntSQLDebug kbbuglist
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |