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#

DROP LOGIN login name

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 ROLLBACK does not bring it back.

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 DROP LOGIN only.

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.