(1) The 'must' gives it away, you don't have to use REVERT or another EXECUTE AS statement to change your context back.

(3) If you're an sa, you can impersonate a user with Execute As User, hence #3 is wrong - a member of the sysadmin role can use database level impersonation.

(4) "Explicitly Defined" in terms of executing as a Login or User - Execute As Login gives you impersonation at the server level, i.e. all databases, Execute As User gives you impersonation at the database only level, you can't switch to another database.

Simon Facer (5/15/2008)(4) "Explicitly Defined" in terms of executing as a Login or User - Execute As Login gives you impersonation at the server level, i.e. all databases, Execute As User gives you impersonation at the database only level, you can't switch to another database.

This one was pretty clear-cut ...

I guess it was clear cut if you defined scope as Server (Login) or Database(Level). The way I defined scope was how long the impersonation lasted. Similar to the scope of a variable in C# or VB, or that you had to explicitly REVERT.

Happened exactly the same to me, cause I choosed 2 & 3. Simply, I'm going to check it out on the SQL Server, and I'll see what happens with the DBO/SYSADMIN issue over the EXECUTE AS command; which as far as I can see has been the hot topic here for most of us.