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


147

J'utilise l'édition développeur de SQL Server 2008. J'essayais de joindre la base de données AdventureWorks2008.

Lorsque j'ai essayé de joindre, j'ai reçu une erreur «l'accès est refusé». Selon le journal des événements, il provenait de l'O / S:

Échec d'ouverture: impossible d'ouvrir le fichier D: \ ProjectData \ AdventureWorks \ AdventureWorksLT2008_Data.mdf pour le fichier numéro 0. Erreur du système d'exploitation: 5 (l'accès est refusé.).

Je pensais "problème NTFS", mais System (et moi) avons modifié l'accès aux deux fichiers.

J'ai constaté que je pouvais joindre la base de données avec succès si je me connectais en tant que sa, mais mon compte d'utilisateur ne fonctionnera pas.

Je suis membre du groupe des administrateurs locaux sur ma machine et je suis dans le rôle d'administrateurs système dans l'instance SQL Server.

Une idée de pourquoi je devais être connecté en tant que sa?


Le fichier MDF est-il crypté par hasard?
Brettski

Non - la vraie curiosité pour moi est que cela fonctionne bien si je me connecte en tant que sa (en utilisant Management Studio), mais cela ne fonctionne pas si j'utilise mon compte administrateur local. Mon compte est un administrateur, un administrateur de domaine et c'est le compte sous lequel j'étais connecté lorsque j'ai installé SQL Server (lors de l'installation, il y avait une option pour faire de mon compte actuel un administrateur système, et je l'ai fait).
JMarsch

1
C'est ainsi que fonctionne UAC dans W7, sans surprise.
Al Kepp

@AlKepp Non - pas un truc UAC. Se connecter simplement en tant que sa corrige (compte de serveur SQL, n'a rien à voir avec UAC) le problème. De plus, simplement en étant membre du groupe d'administrateurs locaux, j'obtiens mes autorisations - je n'ai pas besoin d'élever pour que mes informations d'identification AD fonctionnent.
JMarsch

Réponses:


162

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

SQL SRV EXPRESS 2008 R2. Windows 7


5
L'exécution de Management Studio en tant qu'administrateur n'a PAS fonctionné pour moi. Cette erreur se produit lors de la tentative de démarrage du service Windows.
nuzzolilo

9
L'exécution en tant qu'administrateur est la première étape. La deuxième étape consiste à se connecter à SQL Server via l'authentification Windows. (Cette méthode a fonctionné pour moi!)
Furkan Ekinci

3
A travaillé pour moi aussi. Impossible d'exprimer avec des mots à quel point les invites et les erreurs d'autorisation sont fatigantes et frustrantes sous Windows. JE SUIS UN ADMINISTRATEUR!
David Masters

A travaillé pour moi aussi. Au début, je ne pensais pas que cela fonctionnerait car SSMS n'est qu'un client d'interface utilisateur. Je pensais que le service devait être exécuté en tant qu'administrateur. Mais exécuter SSMS en tant qu'administrateur suffit.
Luke Vo

2
A travaillé pour moi aussi. SQL Server 2019, SSMS 18.4
Ryan Thomas

105

Merci pour tous les commentaires. Certains d'entre vous m'ont aidé à trouver la réponse. Voici ce que j'ai trouvé:

C'était un problème d'autorisation NTFS, et non un problème SQL. De plus, cela ressemble à un bug (et c'est répétable).

Le problème: le compte que j'utilisais avait des autorisations NTFS de contrôle total sur les fichiers mdf et ldf. Cependant, il avait ces autorisations via l'appartenance à un groupe (le groupe Administrateurs locaux avait des autorisations et mon compte est membre d'administrateurs locaux). (J'ai vérifié les autorisations)

Si j'essaie de faire l'attachement, de me connecter à SQL Server en tant que moi (où je suis dans le groupe admins), cela échoue avec le problème NTFS.

Cependant, si j'accorde les mêmes autorisations de fichier que le groupe d'administrateurs local directement sur mon compte de domaine, je peux attacher sans problème.

(oh, et oui, j'ai vérifié les groupes locaux sur cette machine, et j'ai vérifié que mon compte de domaine est bien un membre du groupe des administrateurs locaux).

Ainsi, il semble que l'erreur se produit car un certain code (dans SQL Server ou Management Studio) vérifie les autorisations détenues par le compte d'utilisateur, mais il ne va pas jusqu'à vérifier les autorisations de groupe dont le compte d'utilisateur hérite.

Cela me semble étrange, mais je peux le reproduire encore et encore, alors j'ai conclu que c'était la réponse.

Mise à jour: J'ai signalé cela comme un bogue: https://connect.microsoft.com/SQLServer/feedback/details/539703/access-denied-attaching-a-database-when-permissions-are-inherited


104
Si, comme moi, vous utilisez Windows 7, vous devrez exécuter SQL Server Management Studio en tant qu'administrateur pour éviter d'obtenir cette erreur.
Antony

4
Reproduit sur Win7 Pro à l'aide de SS2008 Express. Même problème pour sqlcmd et SSMS. == Meldung '5120', Ebene '16', Status '101', Server 'DAGO \ SQLEXPRESS', Zeile 1 - 'Die physische Datei' D: \ data \ mssql \ drei.mdf 'kann nicht geöffnet werden. Betriebssystemfehler 5: '5 (Zugriff verweigert) == Accorder un accès complet à l'utilisateur (qui est membre du groupe d'administration local, qui a accès) résout le problème. De plus, exécuter sqlcmd (ou SSMS, je suppose) en tant qu'administrateur ne produit pas cette erreur.
Lumi

1
Anthony Highsky a la réponse. Assurez-vous simplement d'exécuter Management Studio en tant qu'administrateur.
James

Même problème et même solution pour moi. 2008R2, Win 7, etc. Je viens de me ajouter explicitement à la liste de sécurité, et cela a fonctionné. Je suppose que SQL Server peut les lire, une fois attachés, mais pas sous mes informations d'identification lors de la connexion?
Andrew Backer

4
L'exécution de Management Studio en tant qu'administrateur n'a PAS fonctionné pour moi. Cette erreur se produit lors de la tentative de démarrage du service Windows.
nuzzolilo

20

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 car l' utilisateur Windows sous lequel vous êtes connecté devient le seul utilisateur avec des autorisations sur le fichier .mdf! Les autorisations d'origine du fichier .mdf qui incluaient l'utilisateur SQLServerMSSQLUser$<computer_name>$<instance_name>et le compte Administrateurs sont écrasées par l'utilisateur Windows sous lequel vous êtes connecté (pas l'utilisateur du serveur SQL). Boom, toutes les autorisations sont parties comme ça. Alors faites comme d'autres l'ont dit et faites un clic droit sur votre fichier .mdf et vérifiez les autorisations.

J'ai rencontré ce problème car j'ai utilisé SSMS pour me connecter à la base de données (quel que soit le compte de serveur SQL) et détaché la base de données. Après cela, mon utilisateur Windows était le seul à avoir des autorisations sur le fichier .mdf. Donc, plus tard, lorsque j'ai essayé de joindre la base de données en utilisant le compte sa, il a jeté l'erreur «accès refusé».

Pour garder les autorisations d'origine intactes, vous devez mettre la base de données hors ligne, puis la détacher, puis l'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

1
Merci pour cela! Je pense qu'il est beaucoup plus facile de faire les choses correctement si vous êtes également connecté à l'aide d'un compte authentifié SQL Server avec des privilèges serveradmin.
William Rose

Malheureusement, cela ne m'aide pas si j'ai initialement créé la base de données en tant que 'sa' au lieu d'être en tant qu'utilisateur Windows
David Gardiner

"Soyez prudent lorsque vous détachez la base de données". Dites à SSMS d'être prudent. Mes problèmes sont survenus parce que l'utilisation de SSMS la commande Copier la base de données a échoué, me laissant dans la ville de puits sans explication
Alan Macdonald

18

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

Vérifiez ce nom: NT Service\MSSQLSERVER

Et changez le nom Locationde votre serveur.


5
Pour trouver le nom exact du compte, car il peut varier d' une instance à, exécutez: SELECT servicename, service_account FROM sys.dm_server_services.
Arve Systad

13

Ce problème est causé par UAC (User Account Control), n'est-ce pas? Bien que votre compte d'utilisateur soit membre du groupe Administrateurs, l'UAC dans Windows 7 ne vous permet pas d'effectuer des tâches d'administrateur à moins que vous n'exécutiez des programmes «en tant qu'administrateur». Ce n'est pas un vrai bogue 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 «l'erreur 5».)


11

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


1
Cette réponse doit être votée pour. L'exécution du SSMS en tant qu'administrateur est une solution qui réplique cette réponse. Microsoft signale ceci comme "comportement attendu" ici: lien
FreeText

N'est-ce pas la même chose que la réponse de MandoMando?
mortb

10

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

Et puis base de données attachée terminée avec succès.


Cela a fonctionné avec SQL Server 2016 avec Management Studio 2008 R2 sur Windows 10 :)
par

9

Lorsque vous vous connectez en tant que sa(ou n'importe quel compte Sql Server), vous travaillez en tant que compte de service SQL Server, lorsque vous êtes connecté en tant que vous, vous disposez des autorisations de votre compte. Pour une raison quelconque, vous ne disposez pas de l'accès aux fichiers approprié, mais le compte de service en a.


Le problème NTFS a également été la première chose à laquelle j'ai pensé, mais cela ne semble pas être le problème: je suis membre du groupe des administrateurs locaux et j'ai vérifié que les administrateurs avaient des autorisations de «contrôle total» sur les fichiers mdf et ldf . De plus, je suis le propriétaire des fichiers - je venais de créer un répertoire et de copier moi-même les fichiers mdf / ldf à leur emplacement.
JMarsch

@JMarsch: @Nick dit que 'sa' a un ensemble de DROITS SQLSERVER - pas de droits NTFS - que votre compte n'a pas.
Trevoke

@Trevoke: Je suis avec toi. Si tel est le cas, quels droits dois-je attribuer à mon compte utilisateur? (Je suis déjà affecté au rôle d'administrateur système)
JMarsch

1
Ancienne réponse, ceci, mais pour des gens comme moi il y a cinq minutes: vous pouvez trouver le nom d'utilisateur exact du service en exécutantSELECT servicename, service_account FROM sys.dm_server_services
Arve Systad

6

J'ai trouvé cette solution: faites un clic droit sur le dossier dans lequel vous stockez votre fichier .mdf -> cliquez sur Propriétés -> choisissez l'onglet Sécurité, cliquez sur Modifier ... et donnez-lui un contrôle total. J'espère que cela t'aides!


5

L' sautilisateur utilise des comptes NTFS SQLServerMSSQLUser$<computer_name>$<instance_name>etSQLServerSQLAgentUser$<computer_name>$<instance_name> pour accéder aux fichiers de la base de données. Vous voudrez peut-être essayer d'ajouter des autorisations pour l'un de ces utilisateurs ou les deux.

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


5

Avec moi - Exécution sur la fenêtre 8 - Cliquez avec le bouton droit sur SQL Server Manager Studio -> Exécuter avec l'administrateur. -> attacher aucun problème


5

il peut être corrigé facilement mais radicalement, allez simplement dans le dossier où vous avez stocké le fichier mdf . sélectionnez fichier-> clic droit -> cliquez sur les propriétés et donnez les autorisations complètes au fichier pour la sécurité de l'utilisateur connecté .


3

Chaque fois que j'ai rencontré ce problème, c'était lors de la tentative de connexion d'une base de données qui se trouve dans un répertoire différent du répertoire de base de données par défaut configuré dans le serveur SQL.

Je recommanderais vivement qu'au lieu de détourner des autorisations sur divers répertoires et comptes, vous déplaciez simplement votre fichier de données dans le répertoire que le serveur SQL attend de le trouver.


Dans de nombreuses situations, je serais d'accord avec votre point de vue, mais avec le serveur SQL, vous souhaitez souvent pouvoir localiser vos bases de données sur différents axes ou volumes pour l'évolutivité. En fait, il est courant de placer le journal des transactions sur une broche distincte de la base de données afin d'améliorer le débit des transactions.
JMarsch

@JMarsch: Oui .. les répertoires sont en fait configurables via l'onglet Propriétés du serveur> Paramètres de la base de données pour les données par défaut et les emplacements des journaux ...
NotMe

Cela couvre les valeurs par défaut, mais ce ne sont que les valeurs par défaut. Il est tout à fait acceptable de mettre des dbs ailleurs, et ce n'est même pas rare si votre serveur gère plus d'une base de données activement utilisée.
JMarsch

J'ai ce même problème même avec le répertoire de serveur sql par défaut: c: \ Program Files \ Microsoft SQL Server \ MSSQL10_50.SPATIAL_IM \ MSSQL \ DATA \ mydb.mdf sur win7.
goku_da_master

3

Je voulais juste ajouter ces informations également.

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'attachement. Ainsi, les fichiers, une fois détachés, appartenaient à la première connexion, mais la pièce jointe 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 exécuté la commande detach, donc pour résoudre le problème, nous devons modifier ou ajouter l'autre connexion en tant que propriétaire des fichiers mdf et ldf.

Cliquez avec le bouton droit sur le fichier "filename.mdf" et sélectionnez les propriétés pour vérifier les permissions du fichier mdf. Ici, nous pouvons voir qu'un seul compte a la permission sur le fichier "filename.mdf" car c'était le compte qui a été utilisé pour détacher la base de données.

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


J'ai changé ma connexion dans SSMS pour correspondre à l'utilisateur qui a effectué le détachement, et j'ai pu effectuer la connexion.
glitzsfa

2

Pour ce que cela vaut pour quiconque a la variante particulière de ce problème que j'ai eue:

  • SQL Express 2008
  • Visual Studio 2010 Premium

Grâce au 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 les fichiers, à un moment donné même à "Tout le monde". Rien n'a aidé, j'ai donc supprimé à nouveau les autorisations ajoutées.

Ce qui a finalement résolu le problème, c'est d'ouvrir l'Explorateur de serveurs dans Visual Studio, puis de se connecter au MDF et de le détacher à nouveau. Après avoir fait cela, mon application Web pourrait accéder à la base de données très bien.

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


2

J'ai déplacé un fichier mdf de base de données du dossier Data par défaut vers mon dossier asp.net app_data et j'ai 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 à l'emplacement d'origine aux fichiers déplacés et j'ai remarqué que MSSQL $ SQLEXPRESS ne s'était pas vu attribuer d'autorisations sur les fichiers dans leur nouvel emplacement. J'ai ajouté un contrôle complet pour "NT SERVICE \ MSSQL $ SQLEXPRESS" (doit inclure ce service NT) et il est très bien joint.

Il semble que le dossier Data d'origine dispose de ces autorisations et que les fichiers en héritent. Déplacez les fichiers et l'héritage s'arrête 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 ne dispose pas des autorisations MSSQL $ SQLEXPRESS. Hmmm. Je me demande pourquoi SQL Express aime l'un mais pas l'autre?


Cette solution a fonctionné pour moi sur Windows 10 et SQL Server 2017 lors du déplacement d'un fichier journal sur un disque séparé. Dans mon cas, le nom d'utilisateur était "NT SERVICE \ MSSQLSERVER"
John Hanley

1

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 la connexion en tant que vous-même et la connexion en tant que sa? Si vous vous détachez et réessayez, le problème persiste-t-il?


Dans mon cas, non - je l'ai refait plusieurs fois pour m'en assurer. Le problème était que mon compte n'avait accès aux fichiers que via un niveau d'indirection - j'étais membre du groupe Admin de domaine. L'administrateur de domaine était membre du groupe Administrateurs locaux sur la machine et les administrateurs locaux (et le système) avaient un contrôle total sur le dossier. (il y avait donc 2 niveaux d'indirection de groupe). Si je m'attribuais directement des autorisations, cela fonctionnait, si je les supprimais, je pouvais toujours copier / supprimer les fichiers d'Explorere, etc., mais SQL Server ne pouvait pas les charger.
JMarsch

Lorsque vous essayez d'attacher une base de données. Connectez-vous car Windows authenticated usercela nous aidera à surmonter l'autorisation sur les fichiers de base de données. (Ce cas, instance de MS SQLServer sur le disque avec le système d'exploitation Windows).
Do Nhu Vy

1

J'ai eu le même problème lors de la connexion 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 de contrôle / Paramètres de contrôle de compte d'utilisateur / Réglez sur "ne jamais notifier". Enfin, redémarrez l'ordinateur et cela a fonctionné pour moi.


1

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.


1

Je lisais cette page et ils contiennent une phrase intéressante:

Attention: soyez très sélectif lorsque vous ajoutez des utilisateurs à ces rôles. Par exemple, sysadmin correspond à dbo dans chaque base de données et équivaut à se connecter à l'aide du compte sa.

Bien sûr, ils ont aussi ceci:

Autorisations accordées aux utilisateurs et aux rôles et qui sont spécifiques à la base de données. Toutes les autorisations sont cumulatives à l'exception d'un REFUSER. Une autorisation refusée au niveau de l'utilisateur ou au niveau du rôle remplace la même autorisation accordée via d'autres appartenances aux rôles, à l'exception du rôle de serveur fixe sysadmin. (Un administrateur système conserve toutes les autorisations, même si un rôle dont il est membre dispose d'une autorisation DENY.)

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'œil rapide à ces deux pages:
Lien vers les conditions préalables de la base de données

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 de bizarrerie / bord de Microsoft, mais je peux me tromper.


+1 parce que votre commentaire m'a aidé à trouver la réponse. Je publierai mes conclusions sur ce fil. BTW (J'étais "méchant" en raison de politiques très étranges dans lesquelles je travaille - la base de données adventureworks est distribuée sous forme d'exe. Je ne peux pas télécharger d'exe. (Je peux télécharger des fichiers zip et des fichiers MSI, donc je ne vois pas comment le filtrage exe fait vraiment autre chose que de gêner, mais ce sont les règles). Quoi qu'il en soit, je pourrais obtenir les fichiers mdf bruts sous forme de zips à partir de codeplex, et c'est là que j'ai rencontré cette petite curiosité.
JMarsch

1

entrez la description de l'image ici

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

changer pour FOR ATTACH -> FOR ATTACH_FORCE_REBUILD_LOG

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

Merci, vous avez sauvé ma journée
Shahrokhian

1

J'ai eu cette erreur en tant que sa. Dans mon cas, la sécurité de la base de données n'avait pas d'importance. J'ai ajouté à tout le monde le contrôle total des fichiers mdf et ldf, et l'attachement s'est bien passé.


1

J'étais confronté au même problème dans VS 2019.Si quelqu'un est toujours confronté au même problème, veuillez vous assurer que vous avez / faites les choses suivantes:

  1. Vous devriez avoir SQL Express installé sur votre m / c
  2. Devrait avoir SSDT installé dans VS (dans VS 2019 - assurez-vous de vérifier ce composant lors de l'installation) pour les versions précédentes - vous devez ajouter ce composant en externe
  3. Ajoutez 'User Instance = True' à votre chaîne de connexion
  4. Je pense que c'est facultatif - ouvrez VS et SQL Express en mode administratif et connectez-vous en tant qu'administrateur à SQL Express

0

Il s'agit en fait d'autorisations NTFS et d'un étrange bogue dans SQL Server. Je ne suis pas sûr que le rapport de bogue ci-dessus soit exact ou qu'il puisse 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 le chemin. J'ai remarqué que le chemin m'était coupé. En effet, l'utilisateur MS SQL Server (SQLServerMSSQLUser $ machinename $ SQLEXPRESS) que le logiciel ajoute pour vous n'a pas les autorisations pour accéder au dossier (dans ce cas, un dossier situé au fond de mes propres dossiers utilisateur).

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

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

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


0

Si vous exécutez SQL Server 2012, vous pouvez obtenir cette erreur en essayant de joindre une ancienne version d'un fichier mdf. ex un fichier mdf du serveur SQL 2008.


Je pense que cette partie était relativement explicite. il serait bon de savoir comment régler le problème.
dansan

0

J'ai résolu le problème en déplaçant simplement le fichier .mdf que vous souhaitez joindre au dossier public, dans mon cas, je l'ai déplacé vers le dossier users / public. Ensuite, je l'attache à partir de là sans aucun problème. J'espère que cela t'aides.


0

Pour ceux qui n'ont pas pu 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, cliquez avec le bouton droit, propriétés, onglet de sécurité et ajoutez des autorisations de contrôle complet 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 moi).

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


0

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

0

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

entrez la description de l'image ici


0

J'ai eu le même problème lors de la ré-attache de la base de données après l'avoir détachée et le déplacement des fichiers ldf et mdf du lecteur C vers F.

Afin de résoudre ce problème, j'ai dû ajouter le principal DROITS DU PROPRIÉTAIRE aux deux fichiers et lui ai donné un contrôle total sur eux dans l'onglet Sécurité de la boîte de dialogue Propriétés.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.