L'accès est refusé lors de la connexion d'une base de données

Exécutez SQL Server Management Studio en tant qu'administrateur. (clic droit - > exécuter en tant qu'administrateur) qui a pris soin de toutes les bizarreries dans mon cas.

SQL SRV EXPRESS 2008 R2. Windows 7

Je voudrais ajouter des informations supplémentaires aux réponses qui ont été publiées.

Soyez prudent lorsque vous détachez la base de données parce que le Utilisateur windows Vous êtes connecté comme devient le seul utilisateur avec des autorisations à la .fichier mdf! Les autorisations d'origine la .le fichier mdf avait qui comprenait l'utilisateur SQLServerMSSQLUser$<computer_name>$<instance_name> et le compte des administrateurs sont écrasés par l'utilisateur windows que vous êtes connecté (pas l'utilisateur sql server). Boum, toutes les permissions ont disparu comme ça. Alors faites comme les autres ont dit et faites un clic droit sur votre .fichier mdf et vérifiez les autorisations.

J'ai rencontré ce problème parce que J'ai utilisé SSMS pour me connecter à la base de données (peu importe le compte sql server) et détaché la base de données. Après avoir fait cela, mon utilisateur windows était le seul qui avait des autorisations pour le .fichier mdf. Donc, plus tard, quand j'ai essayé d'attacher la base de données en utilisant le compte sa, il a jeté l'erreur "Accès refusé".

Pour garder les autorisations d'origine dans le tact, vous devez prendre le base de données hors ligne, puis détacher, puis attacher dans cet ordre comme suit:

USE [master]
GO
-- kick all users out of the db
ALTER DATABASE mydb
SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
GO

-- Take the Database Offline
ALTER DATABASE mydb SET OFFLINE WITH
ROLLBACK IMMEDIATE
GO

-- detach the db
EXEC master.dbo.sp_detach_db @dbname = N'mydb'
GO

Ajoutez l'autorisation au dossier où se trouve votre fichier .mdf.

Vérifier ce nom: NT Service\MSSQLSERVER

Et remplacez le Location par votre nom de serveur.

Ce problème est causé par UAC (contrôle de Compte D'utilisateur), n'est-ce pas? Bien que votre compte utilisateur soit membre du groupe Administrateurs, L'UAC dans Windows 7 ne vous permet pas de faire des choses d'administrateur sauf si vous exécutez des programmes "en tant qu'administrateur". Ce n'est pas un vrai bug dans SQL Server ou Management Studio ou autre. (Bien qu'il puisse éventuellement connaître le problème et vous demander des autorisations élevées au lieu de simplement se plaindre de "Erreur 5".)

Exécutez SQL Server Management Studio en tant qu'administrateur. (clic droit - > exécuter en tant qu'administrateur) a fonctionné pour moi avec Windows 7-SQL server 2008 R2

Une base de données SQL2005 peut être attachée de cette manière dans Windows 7:

start menu >
 all program >
  Microsoft sql server 2005 >
   sql server management studio >
    right click >
     run as administrator >
      click ok

Puis la base de données jointe a été complétée avec succès.

Lorsque vous vous connectez en tant que sa (ou tout compte Sql Server), vous fonctionnez en tant que compte de service SQL Server, lorsque vous êtes connecté en tant que vous, vous avez les autorisations de votre compte. Pour une raison quelconque, vous n'avez pas l'accès au fichier approprié, mais le compte de service le fait.

L'utilisateur sa utilise les comptes NTFS SQLServerMSSQLUser$<computer_name>$<instance_name> et SQLServerSQLAgentUser$<computer_name>$<instance_name> pour accéder aux fichiers de base de données. Vous pouvez essayer d'ajouter des autorisations pour un ou les deux utilisateurs.

Je ne sais pas si résout votre problème puisque vous dites que vous n'avez aucun problème avec l'utilisateur sa, mais j'espère que cela aidera.

Avec moi - En cours d'exécution sur la fenêtre 8 - Faites un clic droit sur SQL Server Manager Studio - > exécuter avec admin. - >joindre aucun problème

, Il peut être fixe facilement, mais radicaly, il suffit d'aller dans le dossier où vous avez stocké fichier mdf. sélectionnez Fichier - > clic droit - > cliquez sur Propriétés et Donnez toutes les autorisations au fichier pour la sécurité des utilisateurs connectés .

J'ai trouvé cette solution: faites un clic droit sur le dossier où vous stockez votre .fichier mdf - > cliquez sur Propriétés - > choisissez L'onglet Sécurité, cliquez sur Modifier... et lui donner le plein contrôle. Espérons que cette aide!

Chaque fois que j'ai rencontré ce problème, c'était lors de la tentative d'attacher une base de données située dans un répertoire différent du répertoire de base de données par défaut configuré dans SQL server.

Je recommande fortement qu'au lieu de jacking avec des autorisations sur divers répertoires et comptes que vous déplacez simplement votre fichier de données dans le répertoire que sql server attend de le trouver.

, je voulais juste ajouter cette information.

Http://www.mssqltips.com/sqlservertip/2528/database-attach-failure-in-sql-server-2008-r2/

Solution

Vous obtenez cette erreur car deux connexions différentes ont effectué les opérations de détachement et d'attache. Ainsi, les fichiers, lorsqu'ils étaient détachés, appartenaient à la première connexion, mais l'attache a échoué car la connexion utilisée n'était pas le propriétaire des fichiers mdf et ldf.

Lorsque nous détachons des fichiers de base de données, le propriétaire devient la personne qui a fait la commande detach, donc pour résoudre le problème, nous devons changer ou ajouter l'autre connexion en tant que propriétaire des fichiers mdf et ldf.

Faites un clic droit sur le " nom du fichier.mdf" fichier et sélectionnez propriétés pour vérifier les autorisations du fichier mdf. Ici, nous pouvons voir qu'un seul compte a l'autorisation de "nom de fichier.mdf " fichier parce que c'était le compte qui a été utilisé pour détacher la base de données.

Pour résoudre ce problème, cliquez sur Ajouter... bouton pour ajouter l'autre connexion ou toute autre connexion nécessaire et donner le contrôle total de connexion. Vous devriez également le faire pour le fichier "ldf". Une fois cette tâche terminée, cliquez sur le bouton OK. (Remarque pour les autres versions du système d'exploitation, vous pouvez avoir une option D'édition, cliquez d'abord sur cette option, puis vous verrez L'ajout... option.)

Pour ce que ça vaut pour quiconque ayant la variation particulière de ce problème que j'ai eu:

• SQL Express 2008
• Visual Studio 2010 Premium

Dans le menu contextuel du dossier App_data, j'avais créé une base de données SQL Express à des fins de débogage. La chaîne de connexion (utilisée par NHibernate) était la suivante:

Server=.\SQLExpress;
AttachDbFilename=|DataDirectory|DebugDatabase.mdf;
Database=DebugDatabase;
Trusted_Connection=Yes;

Cela m'a donné la même erreur "Accès refusé" sur le fichier de base de données. J'ai essayé de donner à divers utilisateurs un contrôle total sur le dossier et fichiers, à un moment même à "tout le monde". Rien n'a aidé, donc j'ai supprimé les autorisations ajoutées à nouveau.

Ce qui l'a finalement résolu {[15] } était d'ouvrir L'Explorateur de serveur dans Visual Studio, puis de se connecter au MDF et de le détacher à nouveau. Après avoir fait cela, mon application web pourrait très bien Accéder à la base de données.

PS. Les crédits vont à ce blog j'ai trouvé en googlant ce problème particulier, déclenchant l'idée d'attacher / détacher la base de données pour résoudre le problème.

Cela ressemble à des autorisations NTFS. Cela signifie généralement que votre compte de service SQL Server a un accès en lecture seule au fichier (notez que SQL Server utilise le même compte de service pour accéder aux fichiers de base de données, quelle que soit la façon dont vous vous connectez). Êtes-vous sûr de ne pas avoir modifié les autorisations de dossier entre vous connecter en tant que vous-même et vous connecter en tant que sa? Si vous vous détachez et réessayez, a-t-il toujours le même problème?

J'ai eu le même problème lors de la fixation d'une base de données. Ce n'était pas un problème SQL, c'était un problème de Compte. Allez dans le panneau Contrôle / paramètres de contrôle du compte utilisateur / Définir sur "Ne jamais notifier". Enfin, redémarrez l'ordinateur et cela a fonctionné pour moi.

J'ai joint le fichier mdf en cliquant avec le bouton droit sur la base de données et en supprimant le fichier journal AdventureWorks2012_Data_log.ldf dans l'assistant . Le fichier mdf a été placé à l'emplacement suivant

    C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA

La méthode ci-dessus m'a aidé à résoudre le problème .

Je lisais cette page et ils ont une phrase intéressante dans il:

Attention: soyez très sélectif lors de l'ajout les utilisateurs de ces rôles. Exemple, sysadmin cartes à dbo dans chaque base de données et est l'équivalent de connexion à l'aide du compte sa.

Bien sûr, ils ont aussi ceci:

Autorisations accordées aux utilisateurs et les rôles et sont spécifiques à la base de données. Toutes les autorisations sont cumulatives avec l'exception d'un REFUSER. Refusé autorisation au niveau de l'utilisateur ou au niveau d'un rôle remplace le même permission accordée via un autre rôle les adhésions à l'exception de la rôle de serveur fixe sysadmin. (Un sysadmin conserve toutes les autorisations, même si un rôle dont ils sont membres a un Refuser la permission.)

Donc, si vous êtes un administrateur de domaine et dans le groupe SQL 'sysadmin', le monde devrait être votre crustacé.

Bien sûr, selon Microsoft, vous devriez jeter un coup d'oeil à ces deux pages:
lien vers la base de données prérequis

Lien vers L'installation des bases de données

Vous êtes méchant et essayez de les attacher manuellement:) sérieusement, avez-vous tous les prérequis pour la base de données AdventureWorks2008?
Je soupçonne que ce n'est qu'un autre cas Microsoft oddity/edge, mais je pourrais me tromper.

J'ai déplacé un mdf de base de données du dossier de données par défaut vers mon asp.net dossier app_data et a rencontré ce problème en essayant de remettre la base de données en ligne.

J'ai comparé les paramètres de sécurité des autres bases de données de fichiers dans l'emplacement d'origine aux fichiers déplacés et j'ai remarqué que MSSQL $ SQLEXPRESS n'avait pas d'autorisations attribuées aux fichiers dans leur nouvel emplacement. J'ai ajouté un contrôle total pour " NT SERVICE \ MSSQL $ SQLEXPRESS "(doit inclure ce service NT)et il s'est très bien attaché.

Il apparaît que le dossier de données d'origine dispose de ces autorisations et que les fichiers en héritent. Déplacez les fichiers et les pauses d'héritage bien sûr.

J'ai vérifié le fichier mdf d'un autre projet que j'ai créé directement dans son dossier app_data. il n'a pas les autorisations MSSQL $ SQLEXPRESS. Hmmm. Je me demande pourquoi SQL Express Aime l'un mais pas l'autre?

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH
GO

changer pour POUR ATTACHER -- > POUR ATTACH_FORCE_REBUILD_LOG

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH_FORCE_REBUILD_LOG
GO

Il est en fait des autorisations NTFS, et un bug étrange dans SQL Server. Je ne suis pas sûr que le rapport de bogue ci-dessus soit exact, ou peut faire référence à un bogue supplémentaire.

Pour résoudre ce problème sur Windows 7, J'ai exécuté SQL Server Management Studio normalement (pas en tant Qu'administrateur). J'ai ensuite tenté de joindre le fichier MDF. Dans le processus, j'ai utilisé L'interface utilisateur plutôt que de coller dans le chemin. J'ai remarqué que le chemin était coupé de moi. En effet, L'utilisateur MS SQL Server (SQLServerMSSQLUser$machinename$SQLEXPRESS) que le logiciel ajoute pour vous n'a pas les autorisations d'accéder au dossier (dans ce cas, un dossier profond dans mes propres dossiers utilisateur).

Coller le chemin et continuer entraîne l'erreur ci-dessus. Donc-j'ai donné à L'utilisateur MS SQL Server les autorisations de lecture à partir du premier répertoire dont il a été refusé (mon dossier utilisateur). J'ai ensuite immédiatement annulé l'opération de propagation car elle peut prendre une éternité, et à nouveau appliqué les autorisations de lecture au sous-dossier suivant nécessaire, et laissez cela propager complètement.

Enfin, j'ai donné à L'utilisateur MS SQL Server Modifier les autorisations à la .mdf et .fichiers ldf pour la base de données.

Je peux maintenant joindre aux fichiers de base de données.

J'ai eu cette erreur comme sa. Dans mon cas, la sécurité n'avait pas d'importance. J'ai ajouté tout le monde le contrôle total aux fichiers mdf et ldf, et attacher est allé bien.

Si vous exécutez sql server 2012, vous pouvez obtenir cette erreur en essayant de joindre une version antérieure d'un mdf-fichier. ex un fichier mdf de sql server 2008.

J'ai résolu le problème en déplaçant simplement le .fichier mdf que vous souhaitez attacher au dossier public, dans mon cas, je l'ai déplacé vers le dossier Utilisateurs / public. Ensuite, je l'attache à partir de là sans aucun problème. Espérons que cette aide.

Pour ceux qui ne peuvent pas résoudre le problème avec les autres solutions ici, le correctif suivant a fonctionné pour moi:

Accédez à votre dossier "données" dans votre installation SQL Server, faites un clic droit, Propriétés, onglet Sécurité, et ajoutez des autorisations de contrôle total pour l'utilisateur "SERVICE RÉSEAU".

Http://decoding.wordpress.com/2008/08/25/sql-server-2005-expess-how-to-fix-error-3417/

(le lien ci-dessus est pour SQL 2005, mais cela a corrigé une installation SQL 2008 R2 pour je).

Quelques informations supplémentaires: ce problème est apparu pour moi après le remplacement d'un disque dur secondaire (sur lequel L'installation SQL était activée). J'ai copié tous les fichiers et restauré la lettre de lecteur d'origine sur le nouveau disque dur. Toutefois, les autorisations de sécurité n'ont pas été copiées. Je pense que la prochaine fois je vais utiliser une meilleure méthode de copie de données.

Dans mon cas, ce qui a résolu le problème était le suivant:

USE [master]
GO
CREATE DATABASE [AdventureWorks2008R2] ON
( FILENAME = 'C:\Program Files\Microsfot SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\AdventureWors2008R2_Data.mdf')
FOR ATTACH_REBUILD_LOG

Copiez la base de données dans un autre dossier et attachez ou connectez-vous à SQLServer avec "authentification Windows"

J'ai eu le même problème lors de la reconnexion de la base de données après l'avoir détachée et déplacé les fichiers LDF et mdf du lecteur C vers F.

Afin de le réparer, j'ai dû ajouter le principal des droits de propriétaire aux deux fichiers et lui donner un contrôle total sur eux dans l'onglet Sécurité de la boîte de dialogue Propriétés.

J'ai eu du mal avec SSMS (2016) pour joindre la base de données AdventureWorks2012. Mais a eu du succès avec ce code, tiré de un article de CodeProject par Mohammad Elsheimy :

CREATE DATABASE AdventureWorks2012
    ON PRIMARY (FILENAME='D:\Dev\SQL Server\AdventureWorks2012.mdf')
    FOR ATTACH;