DROP LOGIN#
Removes a login from the server. Querona keeps a single tier of principals — a login is a user — so removing the login removes the account entirely, together with its permissions and its role memberships.
Syntax#
Arguments#
login_name
The name of the login to remove. For a Windows principal this is the fully qualified DOMAIN\name. The name
must belong to a login: naming a role is refused the same way naming a login that does not exist is (error
15151), so the statement cannot be used to find out which principals exist.
IF EXISTS is not supported, matching SQL Server, which has no such clause on this statement.
Remarks#
Removing a login takes its access rights and its role memberships with it. Objects it owned — databases, schemas and tables — are not removed and do not block the removal: they lose their owner and stay in place.
An account Querona owns cannot be removed: the internal System account and the Spark reverse account are refused with error 15405. An administrator account is an ordinary login and can be removed by any caller with the Alter any login permission — including the account they are signed in with, once its own session is closed.
A login that still has an open session cannot be removed (error 15434). This includes the session running the statement, which is how the statement stops an account removing itself, and it includes sessions a client library is holding in its connection pool: closing the application’s connection object is not always enough.
DROP LOGIN is server-wide: it may be executed from any database and it takes effect on every node of the
cluster.
Differences from SQL Server#
Behaviour |
Querona |
|---|---|
The login owns a database |
The removal succeeds and the objects lose their owner. SQL Server refuses with error 15174 and asks you to change the owner first. This follows Querona’s ownership model, which the user management screen has always used. |
The statement is transactional |
No. The account is removed immediately, and a surrounding |
Removing an account from user management |
Behaves as before, with one addition: the System and Spark reverse accounts are now refused there
too. The open-session rule applies to |
Examples#
Remove a password account.
DROP LOGIN jkowalski;
Remove a domain account or a domain group.
DROP LOGIN [CONTOSO\jkowalski];
DROP LOGIN [CONTOSO\Analysts];
Check that it is gone. The type predicate is required: principal_id is not unique across logins and
roles.
SELECT name FROM sys.server_principals WHERE type <> 'R' AND name = 'jkowalski';
Errors#
Error |
Raised when |
|---|---|
15151 |
The login does not exist, the name belongs to a role, or the caller does not hold the Alter any login permission. The three cases are deliberately indistinguishable. |
15405 |
The principal is an account Querona owns rather than a user’s login. |
15434 |
The principal still has an open session — including the session running the statement. |
Permissions#
Requires the Alter any login permission, held by the securityadmin role.