Microsoft KB Archive/280101

= INF: Transact-SQL Debugger Limitations and Troubleshooting Tips for SQL Server 2000 =

Article ID: 280101

Article Last Modified on 11/30/2005

-

APPLIES TO


 * Microsoft SQL Server 2000 Standard Edition

-



This article was previously published under Q280101



SUMMARY
This article describes the limitations of Transact-SQL Debugger in SQL Server 2000. This article also provides guidelines and directions to troubleshoot basic problems related to Transact-SQL Debugger. However, this is not an exhaustive list, and some problems may be specific to your environment.



Limitations with Transact-SQL Debugger
 You cannot debug a stored procedure from the terminal client computer through a terminal server session. You may receive the following error message in the Event Viewer Application log:

Unable to connect to debugger on  (Error = 0x80070057 The parameter is incorrect. ). Ensure that client side components such as SQLLE.DLL are installed and registered on. Debugging disabled for connection.

For additional information about how to solve this problem, click the following article number to view the article in the Microsoft Knowledge Base:

280100 BUG: Transact-SQL Debugger Is Not Available Through Terminal Server Session

 If you have installed different versions of SQL Server on one computer, the debugger of the named instance uses the SQL Server startup account of the default instance. You cannot debug the OLE Automation extended stored procedures (sp_OA*) in Transact-SQL Debugger by using the Step Into (F11) option or any other extended stored procedures because extended stored procedures are actually DLLs that are written in languages other than SQL. For additional information about how to debug extended stored procedures, click the following article number156099 to view the article156099 in the Microsoft Knowledge Base:

../ HOW TO: Debug an Extended Stored Procedure

 You cannot debug stored procedures that contain the RAISERROR statement. (The RAISERROR statement raises errors that have a severity 16 or higher.) For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

280099 BUG: Transact-SQL Debugger Cannot Debug a Stored Procedure that Contains a RAISERROR Statement that Raises any Error with Severity 16 or Higher

 You can only run one stored procedure in debug mode in a SQL Query Analyzer session. SQL Query Analyzer does not support multiple instances of Transact-SQL Debugger. When you try to debug a second stored procedure in the same SQL Query Analyzer session, you are prompted to cancel the active debugging stored procedure. You cannot modify the active stored procedure in debug mode. The object that starts the debugging process is locked. Because it is locked, you are prevented from making any modifications except for printing and scripting. Because of connection constraints, you cannot create a new query while the debugger window is in the foreground. To create a new query, either bring an existing query window to the foreground or open a new connection to the database. In debug mode, variables of the table data type do not appear in the local variables window.</li> In debug mode, variables of sql_variant, text, ntext, image, and cursor data types appear in the local variables window. You cannot modify these variables.</li> Microsoft does not support debugging stored procedure greater than 128K.</li> Microsoft does not support debugging nested stored procedure greater than 32 stored procedure calls.</li> Microsoft does not support debugging a stored procedure that has more than 1023 arguments.</li> In debug mode, local variables windows watch expression displays only the first 255 characters for varchar, char and nvarchar local variables.</li></ol>

Troubleshooting the Transact-SQL Debugger
<ol> See the &quot;SQL Server Tools Troubleshooting&quot; topic in SQL Server Books Online.</li> Examine SQL error logs and the Application and System logs in Event Viewer.</li> SQL debugging uses distributed COM (DCOM) to communicate between the client computer and the database server. You must configure DCOM to allow remote users to attach the debugger to a process on the database server. Problems may occur if the DCOM permission settings are incorrect.

For more information about DCOM permission settings, visit the following Microsoft Web sites:

Troubleshooting the Transact-SQL Debugger

Setting Machine-Wide Security Using DCOMCNFG

</li> Make sure that the remote procedure call (RPC) services are started on the server.</li> Make sure that you have the correct versions of Transact-SQL Debugger component files. <ul> Server components include Mssdi98.dll and Sqldbg.dll.</li> Client components include Sqldbreg.exe and Sqldbg.dll.</li></ul>

The Mssdi.dll file should be in the same folder as the Sqlservr.exe file. By default, Mssdi.dll is in the BINN folder. By default, Sqldbg.dll and Sqldbreg.exe are in the Program Files\Common Files\Microsoft Shared\SQL Debugging folder.</li> Use the Domain User account (and not the Local System account) as the SQL Server service account and that the Domain User account is a member of the Local Administrators group for remote debugging. For example, the following error message is logged in the Application log when the SQL Server logon account is set to use the Local System account:

SQL Server when started as service must not log on as System Account. Reset to logon as user account using Control Panel.

For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

281649 PRB: SQL Server Debugging with Visual Studio Service Pack 5 Requires a Non-System Account

</li> It is not a good idea to use Transact-SQL Debugger on a production server. While in step execution mode, the debugger can lock certain system resources that other processes must access.</li></ol>

<div class="references_section">