|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
How to: Set SQL Server Permissions for Debugging
This topic applies to:
Pro and Team
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.
By default, Windows administrators on a computer that is running SQL Server are SQL Server sysadmins on that computer.