In a Microsoft SQL Server 2000 environment, you are the administrator of a server named CorpSQL in the Windows NT domain CORPORATE. A user named Franz has only a local user account on CorpSQL and is a member of the local Power Users group. He requests access to the SQL Server databases stored on CorpSQL. Which Transact-SQL statement should you execute to allow Franz to log in to SQL Server by using his local Windows account?

Introduction / Context:
This question tests your understanding of how Windows authentication works in SQL Server 2000, especially the difference between local user accounts on a member server and domain user accounts. The scenario focuses on granting a login to SQL Server for a user who exists only in the local Security Accounts Manager database on the server named CorpSQL.

Given Data / Assumptions:

• SQL Server 2000 is running on a computer named CorpSQL.
• CorpSQL is a member server in the Windows NT domain named CORPORATE.
• Franz has a local user account on CorpSQL, not a domain account.
• Franz is a member of the local Power Users group on CorpSQL.
• You are using Windows authentication and the sp_grantlogin stored procedure.

Concept / Approach:
SQL Server 2000 supports Windows authentication based on Windows security principals. When you grant a login for a Windows user, you must specify the fully qualified Windows account in the form ServerName\\UserName for local accounts or DomainName\\UserName for domain accounts. Because Franz is defined locally on CorpSQL, SQL Server sees him as CorpSQL\\Franz, not CORPORATE\\Franz. The sp_grantlogin procedure is used to add a Windows login to SQL Server so that the account can authenticate and then be mapped to database users and permissions.

Step-by-Step Solution:
Step 1: Identify whether Franz is a domain user or a local user. The problem states that he maintains a local user account on CorpSQL.Step 2: Recall that local accounts are referenced as ServerName\\UserName, so Franz is CorpSQL\\Franz.Step 3: Remember that sp_grantlogin is used with a Windows account name to grant a SQL Server login for that account.Step 4: Select the Transact-SQL statement that uses CorpSQL\\Franz as the parameter to sp_grantlogin.

Verification / Alternative check:
If Franz were a domain user, his account would be CORPORATE\\Franz. However, the scenario explicitly states that he has a local account on CorpSQL. Local group membership such as Power Users does not change the fact that the actual security principal is the local user. Checking SQL Server documentation confirms that Windows logins for local accounts are written as MachineName\\UserName when granting access through Windows authentication.

Why Other Options Are Wrong:
Option b uses only Franz without a qualifying machine or domain name, which is not a valid Windows account identifier in this context. Option c incorrectly constructs an account name that mixes group and user syntax and does not represent a real principal. Option d incorrectly assumes that Franz is a domain account in CORPORATE, which contradicts the scenario. Option e invents a nonstandard prefix that SQL Server will not recognise as a Windows security principal.

Common Pitfalls:
A common mistake in exam scenarios is to assume all users are domain users, especially when a domain is mentioned. Another pitfall is to confuse local group membership with domain group membership. Always read carefully whether the account is local or domain based and format the Windows account name correctly when using stored procedures such as sp_grantlogin. Misidentifying the security context can lead to failed logins and inconsistent security configuration.

Final Answer:
You should execute EXEC sp_grantlogin 'CorpSQL\\Franz' to grant a SQL Server login to the local Windows user account that exists on CorpSQL.