PRB: Breakpoints Not Hit in Multiple Line SQL Statements
Article ID: 169403
Article Last Modified on 12/10/2003
APPLIES TO
- Microsoft Visual C++ 4.2 Enterprise Edition
- Microsoft Visual C++ 5.0 Enterprise Edition
- Microsoft Visual C++ 6.0 Enterprise Edition
- Microsoft Visual Basic 5.0 Enterprise Edition
This article was previously published under Q169403
SUMMARY
MORE INFORMATION
In the case of the UPDATE statement listed above, the debugger will allow
breakpoints to be placed on the SET clause to the UPDATE statement because
SET is a valid SQL command. Unfortunately, the breakpoint will not be hit
because SET is part of the multiple line UPDATE statement and therefore not
considered a separate SQL statement.
SYMPTOMS
When trying to debug stored procedures, it is possible to run into the
following behavior. Examples are listed below:
UPDATE <table1>
SET <column>=0 WHERE -- SET clause of UPDATE statement is an invalid
breakpoint
SELECT * FROM <table1> where NOT EXIST
(SELECT * FROM <table2> WHERE... ) -- subselect statement is an
invalid breakpoint
CAUSE
The problem is that the debugger will allow invalid breakpoints set on
certain SQL statements. The problem with this behavior is that the break
point is never hit.
RESOLUTION
The listed behavior is inherent in the lexer because it is based on what is
in the first line and does not handle multiple line SQL statements.
STATUS
Microsoft has confirmed this behavior to be by design in the Microsoft
products listed at the beginning of this article.
Additional query words: vcbuglist500 kbVS97 kbVBp500 kbVC420 kbVC500 kbVC600 kbdse kbDSupport
Keywords: kbprb KB169403