Chapter 1: System Procedures

sp_droplogin

Drops an Adaptive Server user login by deleting the user’s entry from master.dbo.syslogins.

sp_droplogin loginame

Drops the “victoria” login from Adaptive Server:

sp_droplogin victoria

Executing sp_droplogin drops a user login from Adaptive Server, deleting the user’s entry from master.dbo.syslogins.
Adaptive Server reuses a dropped login’s server user ID, which compromises accountability. You can avoid dropping accounts entirely and, instead, use sp_locklogin to lock any accounts that will no longer be used.

If you need to drop logins, be sure to audit these events (using sp_audit) so that you have a record of them.
sp_droplogin deletes all resource limits associated with the dropped login.
sp_droplogin fails if the login to be dropped is a user in any database on the server. Use sp_dropuser to drop the user from a database. You cannot drop a user from a database if that user owns any objects in the database.

Regardless, the login is dropped if the database is offline.
If the login to be dropped is a System Security Officer, sp_droplogin verifies that at least one other unlocked System Security Officer’s account exists. If not, sp_droplogin fails. Similarly, sp_droplogin ensures that there is always at least one unlocked System Administrator account.

Only a System Security Officer can execute sp_droplogin.

Values in event and extrainfo columns from the sysaudits table are:

Event	Audit option	Command or access audited	Information in extrainfo
38	exec_procedure	Execution of a procedure	Roles – Current active roles Keywords or options – NULL Previous value – NULL Current value – NULL Other information – All input parameters Proxy information – Original login name, if set proxy in effect