Article ID: 172099 - View products that this article applies to.
This article was previously published under Q172099
This article has been archived. It is offered "as is" and will no longer be updated.
After you install both SQL Server and Visual Basic Enterprise Edition on your local computer, you can perform local SQL debugging. When you run the local SQL debugger after remote debugging (Visual Basic and SQL Server reside on two different computers), the T-SQL debugger starts to skip breakpoints that are set in the SQL stored procedure with the following error message:
The Event Viewer application log on the server reveals the following error message with a source of MSDEVSDI:
"The query could not be debugged due to a problem coordinating events with the server. Check the server and client log to find the exact cause, fix the problem and try again."
"CreateDispatch failed (Class not registered). Check to make sure Automation manager is running on debugger machine."
When you install the T-SQL Debugger client-side component, Visual Basic creates several registry keys for VBSDISERVR.SDIEVENT under HKEY_CLASSES_ROOT in the registry. The LocalServer32 key for VBSDISERVR.SDIEVENT's CLSID is one of the keys that local SQL debugging uses. When you perform remote debugging from another computer, this key is deleted, and some other keys for inprocServer are created. If you perform local SQL debugging after a remote SQL debugging session has been performed, Automation Manager cannot find the LocalServer32 key in the registry, which results in the above-mentioned error message.
To temporarily work around this problem, you can use Regedit.exe to add the LocalServer32 key manually to enable the next local SQL debugging instance; however, this key is deleted again after another remote SQL debugging.
Steps to Add the LocalServer32 Key:
(http://support.microsoft.com/kb/145679/EN-US/ )HOWTO: Use the Registry API to Save and Retrieve Setting
This problem only occurs with local debugging; it does not occur during remote debugging.