How to: Set SQL Server Permissions for Debugging
This topic applies to:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
---|---|---|---|---|
Express |
||||
Standard |
||||
Pro and Team |
Table legend:
Applies |
|
Does not apply |
|
Command or commands hidden by default. |
This section describes the permissions that are required for SQL debugging. These permissions are only those imposed by SQL debugging; there may be other permissions that are required elsewhere. For example, to debug a process that is running as a different user than your Windows login account, the account must be a member of the system administrators group for the computer. For more information, see Remote Debugging Permissions.
There are two user accounts you have to consider.
The application account is the user account that Visual Studio or the client application is running under. This account is a Windows user account, and must be a member of the sysadmin group in the SQL Server being debugged.
The connection account is the identity used to make the connection to SQL Server. This is the account you enter when you define the connection in Server Explorer or that you specify in the connection string when the application connects to a database. This account may be a Windows user account, using Windows Authentication, in which case it is the same account as the Windows account Visual Studio is running under. Or the connection account may be a SQL Server login account. For SQL Server 2005 debugging, the connection account must be a member of the sysadmin role.
To add a Windows login account as sysadmin
A user who already has sysadmin privileges must execute the following:
sp_addsrvrolemember 'Domain\Name', 'sysadmin'
where Domain\Name represents the Windows login account.
Note
By default, Windows administrators on a computer that is running SQL Server are SQL Server sysadmins on that computer.
See Also
Tasks
How to: Enable SQL Server 2005 Debugging