SQL Server: connexion réussie mais "la base de données [nom_bdd] n'est pas accessible. (ObjectExplorer)"
J'utilise Windows 8.1 et SQL Server 2012.
J'utilisais un compte de système d'exploitation "Manoj" pour accéder à SQL SERVER avec l'authentification Windows . Récemment, j'ai supprimé mon compte d'utilisateur "Manoj" du système d'exploitation et créé un nouveau compte portant le même nom "Manoj".
Mais le système a pris le nouveau compte comme "Manoj_2". Cette modification m'empêche d'accéder aux anciennes bases de données que j'ai créées.
Il dit que
La base de données [nom_base] n'est pas accessible. (ObjectExplorer)
chaque fois que j'essaie d'accéder aux bases de données précédentes que j'ai créées.
J'avais l'habitude de créer une nouvelle connexion dans SQL Server pour "Manoj_2", avec DB par défaut en tant que "maître". Mais le problème persiste.
Je ne peux pas détacher les DB. Je ne parviens pas à développer les bases de données.
Remarque: sous OS, j'ai les droits d'administrateur pour le compte "Manoj".
S'il vous plaît, quelqu'un me dit, que faire? soit avec OS ou avec SQL Server
Pour cette situation, vous devez vous connecter à la base de données en Mode mono-utilisateur .
Le démarrage de SQL Server en mode mono-utilisateur permet à tout membre du groupe Administrateurs local de l'ordinateur de se connecter à l'instance de SQL Server en tant que membre du rôle de serveur fixe sysadmin.
Ici, vous pouvez trouver instructions pas à pas faire ceci.
En bref, vous devez démarrer l’instance sqlserver avec les paramètres -m, puis démarrez Sql Server Management Studio avec l’authentification Windows.
Maintenant que vous êtes un sysadmin, assignez le rôle sysadmin à votre utilisateur, quittez et supprimez le paramètre -m et redémarrez le serveur SQL.
Solution vraiment stupide mais je l'ajouterai ici au cas où quelqu'un y arriverait à partir d'une recherche Google.
Je venais juste de redémarrer le service SQL et j'obtenais cette erreur. Dans mon cas, attendre 10 minutes suffisait et tout se passait bien. On dirait que c'est l'erreur que vous obtenez quand vous démarrez.
Le problème est que l'utilisateur dans la base de données est un "orphelin". Cela signifie qu'il n'y a pas d'identifiant de connexion ou de mot de passe associé à l'utilisateur. Cela est vrai même si un identifiant de connexion correspond à l'utilisateur, car il existe un GUID (appelé SID dans Microsoft-speak) qui doit également correspondre.
Auparavant, c'était une tâche difficile à résoudre, mais actuellement (SQL Server 2000, SP3), il existe une procédure stockée qui effectue le gros du travail.
Toutes ces instructions doivent être effectuées en tant qu'administrateur de base de données, avec la base de données restaurée sélectionnée.
Tout d'abord, assurez-vous que c'est le problème. Cela va lister les utilisateurs orphelins:
EXEC sp_change_users_login 'Report'
Si vous avez déjà un identifiant et un mot de passe pour cet utilisateur, corrigez-le en procédant comme suit:
EXEC sp_change_users_login 'Auto_Fix', 'user'
Si vous voulez créer un nouvel identifiant et mot de passe pour cet utilisateur, corrigez-le en procédant comme suit:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
ce texte a été obtenu sur http://www.fileformat.info/tip/Microsoft/sql_Orphan_user.htm dans Dez-13-2017
This is caused when the user's default database is set to a database they don't have permissions or its offline.
Essayez simplement d’ajouter l’utilisateur.Pleae jetez un coup d’œil ici aussi.
C'est ce qui m'a amené à ce problème et comment je l'ai résolu:
Restauré ma base de données sur une autre instance de serveur SQL à partir d'un fichier .bak, qui comprenait un utilisateur préexistant.
Essayé d'accéder à la base de données restaurée à partir de mon application comme d'habitude en utilisant la même chaîne de connexion mais une instance de serveur mise à jour.
Erreur reçue.
Utilisateur supprimé en tant que propriétaire de la base de données, puis redéfini avec les mêmes informations d'identification, mappages, identifiants, etc.
Était capable de se connecter en tant qu'utilisateur après lecture de l'utilisateur après la restauration.
Cela a résolu le problème pour moi:
Use [dbName]
GO
EXEC sp_change_users_login 'Auto_Fix','Manoj', null, 'Manojspassword'
GO
Aller à
Sécurité >> Connexions >> Clic droit sur l'utilisateur >> Propriétés >>
Sur la navigation de gauche, déplacez-vous vers >> Cartographie de l'utilisateur >> Vérifiez la base de données et dans "Appartenance au rôle de base de données pour: <>", cochez "propriétaire_db" pour indiquer à l'utilisateur que vous rencontrez le problème.
PROBLÈME RÉSOLU...
J'avais deux utilisateurs: l'un qui avait le rôle d'administrateur système, l'autre (celui qui posait problème) n'en avait pas.
Je me suis donc connecté avec l'autre utilisateur (vous pouvez en créer un nouveau) et j'ai coché la case 'sysadmin' de ckeck dans: Sécurité -> Connexions -> Bon clic sur votre nom d'utilisateur SQL -> Propriétés -> Rôles de serveur -> assurez-vous que la case à cocher 'sysadmin' est cochée . Appuyez sur OK et essayez de vous connecter avec le nouvel utilisateur coché.
Si vous utilisez Sql Management Studio, démarrez-le simplement en tant qu'administrateur.
Clic droit-> Exécuter en tant qu'administrateur
Dans mon cas, cela a fonctionné lorsque j'ai ouvert SQL Server Management Studio avec les informations d'identification de l'administrateur et j'ai cliqué avec le bouton droit de la souris sur la base de données et sélectionné " Aller en ligne " ou quelque chose du genre.
Mon problème a été résolu en redémarrant le service du serveur MS SQL, simple.
J'ai rencontré un problème similaire après l'exécution de quelques travaux d'insertion en bloc via un script Python sur une machine distincte et un utilisateur distinct de celui que je me connecte à SSMS.
Il semble que si le noyau Python (ou éventuellement toute autre connexion) est interrompu au milieu d'un travail d'insertion en bloc sans «nettoyer» correctement le gâchis, une sorte de blocage lié aux informations d'identification de l'utilisateur et aux verrous peut se produire côté SQL Server. . Ni le redémarrage du service, ni la machine entière n'a fonctionné pour moi.
La solution dans mon cas était de mettre la base de données hors ligne et en ligne. Dans SQL Server Management Studio, cliquez avec le bouton droit de la souris sur DB> tâches> déconnecter, puis cliquez avec le bouton droit de la souris sur DB> tâches> mettre en ligne.
Dans mon cas, le redémarrage du service SQL Server était suffisant pour résoudre le problème.
Dans mon cas, je devais simplement démarrer l'application avec "Exécuter en tant qu'administrateur" pour pouvoir accéder à n'importe quoi. Sinon, j'obtiendrais l'erreur que vous avez mentionnée.
S'il vous plaît essayez ce script .. Ce script fait qu'il regarde les sessions actives de la base de données et les tue afin que vous puissiez remettre la base de données en ligne.
CREATE TABLE #temp_sp_who2
(
SPID INT,
Status VARCHAR(1000) NULL,
Login SYSNAME NULL,
HostName SYSNAME NULL,
BlkBy SYSNAME NULL,
DBName SYSNAME NULL,
Command VARCHAR(1000) NULL,
CPUTime INT NULL,
DiskIO INT NULL,
LastBatch VARCHAR(1000) NULL,
ProgramName VARCHAR(1000) NULL,
SPID2 INT
, rEQUESTID INT NULL --comment out for SQL 2000 databases
)
INSERT INTO #temp_sp_who2
EXEC sp_who2
declare @kill nvarchar(max)= ''
SELECT @kill = @kill+ 'kill '+convert(varchar,spid) +';'
FROM #temp_sp_who2
WHERE DBName = 'databasename'
exec sp_executesql @kill
ALTER DATABASE DATABASENAME SET ONLINE WITH IMMEDIATE ROLLBACK
Problème: la base de données [nombase] n'est pas accessible. (ObjectExplorer) a eu l'erreur lors du développement de la base de données.
Solution: Détachez la base de données> Option Drop Attachez à nouveau la base de données avec le fichier mdf dans le dossier de données mssql.