web-dev-qa-db-fra.com

Drop Login échoue sur SQL Server 2014

Nous avons une base de données avec un propriétaire 'dbowner'. Notre procédure d'installation goutte la connexion pour l'utilisateur 'dbowner' et le crée à nouveau.

Sur toute autre version de SQL Server, la requête SQL suivante réussit:

USE [master]
DROP LOGIN 'dbowner'

Sur SQL Server 2014, la même requête renvoie l'erreur suivante:

Login 'Dbowner' possède une ou plusieurs bases de données (s). Changez le propriétaire de la ou des bases de données avant de laisser tomber le login.

Quelqu'un peut-il expliquer pourquoi cela serait différent sur SQL Server 2014? La goutte de connexion fonctionne sur toutes les autres versions de SQL Server (2005, 2008 et 2012).

Y a-t-il un paramètre pour forcer la même chose à travailler sur SQL Server 2014?

Mettre à jour:

Je peux reproduire cela avec un exemple qui utilise les utilisateurs Windows. Des idées?

CREATE LOGIN [comp\winuser] FROM WINDOWS;
GO
CREATE DATABASE mydb;
GO
ALTER AUTHORIZATION ON DATABASE::mydb TO [comp\winuser];
GO
DROP LOGIN [comp\winuser];
GO

Mise à jour 2:

Merci pour vos commentaires. Je suis d'accord que l'abandon de la connexion du propriétaire n'est pas souhaitable (mais fonctionne avec l'utilisateur Windows partout, sauf sur SQL Server 2014). Cependant, nos scripts d'installation en dépendent actuellement et la procédure d'installation de la base de données extrêmement complexe a été faite par certains gars il y a 15 ans (il ne travaille plus avec nous). C'est un domaine que nous aimons éviter de changer si possible (tant que cela fonctionne).

Comme je le vois, nous avons trois options:

  1. Faites de SQL 2014 pour agir comme les versions précédentes et laissez les scripts comme ils sont. Nous préférons cette option et j'ai posté ici pour voir si cela pourrait être fait.
  2. Changez le propriétaire en un autre utilisateur, déposez et créez le propriétaire Connectez-vous et déplacez le propriétaire. Ceci est un hack mais pourrait fonctionner.
  3. Changez la façon dont nous traitons les utilisateurs et arrêtons de laisser tomber la connexion du propriétaire. Ce serait la bonne voie, mais aussi le plus gros changement.
sql-serversql-server-2014securityuserslogins
3
matjazr

Pour les connexions d'authentification SQL, ce n'est pas différent dans SQL Server 2014 que dans les versions précédentes. Je viens de faire cela en 2008:

CREATE LOGIN dbowner WITH PASSWORD = 'x', CHECK_POLICY = OFF;
GO
CREATE DATABASE mydb;
GO
ALTER AUTHORIZATION ON DATABASE::mydb TO dbowner;
GO
DROP LOGIN dbowner;
GO

MSG 15174, niveau 16, état 1
Login 'Dbowner' possède une ou plusieurs bases de données (s). Changez le propriétaire de la ou des bases de données avant de laisser tomber le login.

Je ne peux pas laisser tomber la base de données avant de le faire:

ALTER AUTHORIZATION ON DATABASE::mydb TO sa;

Pour les connexions d'authentification Windows, comme indiqué Dan, avant le SQL Server 2014, ce chèque n'a pas été effectué pour les connexions de Windows, de sorte que vous puissiez laisser des bases de données dans un état bizarre en supprimant leur propriétaire. Votre deuxième option vous semble préférée et cela signifie uniquement ajouter la ligne ci-dessus à votre script. Une autre option consiste à ne pas fabriquer une fenêtre de connexion au propriétaire (je ne sais pas pourquoi vous les faites propriétaire au lieu de simplement leur donner des droits appropriés dans la base de données) ou arrêtez de laisser tomber les connexions dans le cadre du processus, ou les deux .

6
Aaron Bertrand