How SQL Debugging Works

Feature Only in Enterprise Edition   This feature is supported only in Visual C++ Enterprise Edition. For more information, see .

The SQL Server side has three primary SQL debugging components: AUTPRX32.DLL, AUTMGR32.EXE, and SDI50.DLL. They all must be on the path for the environment that the server is running in. The client side has two primary components: AUTMGR32.EXE and AUTPRX32.DLL.

When the client application begins making SQL Server connections through ODBC and DBLib, tracing turns on at the SQL Server side via a system level call or stored procedure. Once tracing begins, the SDI50.DLL on the server side exposes SQL Server events. The automation manager (AUTMGR32.EXE) functions as a proxy for remote OLE by determining where the server is located and providing remote procedure calls.

Depending on how the application accesses the SQL Server, the debugging context is for either the client application or the SQL Server.  For example, you begin debugging by stepping through a client application just as you would for a normal debugging session. If the application uses an ODBC call to a stored procedure, you can step to that line. As soon as the application makes a call to the SQL Server, you can step into the stored procedure. You have execution control over the SQL source until you either step completely through it or release it. Debugging then continues for the client application. For the remainder of the debugging session, the debugging context switches back and forth between the client application and the SQL Server.