Previous Topic Next topic Print topic


Debugging Stored Procedures under SQL Option

You can request that the server invokes the debugger on all stored procedures by using a setting in the xdb.ini file in the \mfuser\config directory. In the xdb.ini server section, the StProcAnimate variable should be set to "yes" to have the server invoke the debugger on all stored procedures. The server reads this variable every time it starts. The server must be shutdown and restarted for changes to the StProcAnimate variable to take effect. The following is an example of what the variable should look like:

[CLIENT]
XDBCFG=c:\mfuser\config\
[SERVER]
XDBSERVE=myserver
XSRVCFG=c:\mfuser\config
StProcLoadLib=c:\mfuser\projects\MyProject\LOADLIB
StProcAnimate=yes
.
.
.

When the server invokes the debugger for a stored procedure, a second window opens, showing the stored procedure code. All stored procedures that are debugged after this point appear in a new second window.

Do not make changes to stored procedure source code in the second window, as this window does not have a current project and is useful only for debugging a stored procedure. After a stored procedure has been debugged in a second window you may close this window. A new window appears for each stored procedure you are debugging.

The server runs the stored procedure as a separate process. Each call to a stored procedure from a user application will result in a new process being started. However, the process that is created for scalar and table functions will exist and be reused by the server until the original query containing the scalar and/or table function has been closed. Now, every stored procedure that gets loaded (even if it is a second copy of the same stored procedure) will get a new debug session.

Once a stored procedure exits, the debugging session terminates and can be closed. However in the case of scalar and table functions, the same debugging session will be used for each pass through the stored procedure because the stored procedure doesn't actually exit until the scalar/table function calling it is no longer needed. The stored procedure will exit in this case when the query that originally invoked the scalar/table function is closed. In the case of scalar/table functions, a breakpoint should be set on the first statement in the program if you want to stop and debug on successive calls to the stored procedure.

Previous Topic Next topic Print topic