FIX: SQL Breakpoint Not Hit After Executing SP in Another DB (165420)
The information in this article applies to:
- Microsoft Visual C++, 32-bit Enterprise Edition 5.0
This article was previously published under Q165420 SYMPTOMS
The 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.
CAUSE
The 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.
RESOLUTION
Work around this by placing a call to a stored procedure that resides in
the same database as the stored procedure you were initially debugging.
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed
at the beginning of this article. This problem was corrected in Visual C++
version 6.0 for Windows.
REFERENCESSample 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)
| Modification Type: | Major | Last Reviewed: | 10/15/2002 |
|---|
| Keywords: | kbBug kbcode kbDebug kbEEdition kbProgramming kbVC600fix KB165420 kbAudDeveloper |
|---|
|