J'ai déplacé une base de données de SQL Server 2012 vers Azure. Je ne veux pas utiliser l'utilisateur master
, j'ai donc créé un utilisateur test
. Voici ce que j'ai fait pour la base de données XXX sur Azure:
create user test from login test with default_schema=[dbo]
exec sp_addrolemember 'db_owner','test'
J'ai vérifié, et les objets de base de données qui m'intéressent sont tous dans le schéma dbo
. La table Users
est dans le schéma dbo
.
La chaîne de connexion de mon projet Web a test
comme identifiant. Cela produit le message d'erreur:
The SELECT permission was denied on the object 'Users', database 'XXX', schema 'dbo'
Que signifie le message d'erreur et que puis-je faire pour permettre à l'utilisateur test
d'accéder à la base de données XXX?
Je pense que le problème est avec l'utilisateur ayant refuser les privilèges . Cette erreur survient lorsque l'utilisateur que vous avez créé ne dispose pas des privilèges suffisants pour accéder à vos tables dans la base de données. Accordez le privilège à l'utilisateur pour obtenir ce que vous voulez.
GRANT les autorisations spécifiques à l'utilisateur telles que SELECT, INSERT, UPDATE et DELETE sur les tables de cette base de données.
La syntaxe pour accorder l'autorisation de sélection est la suivante:
USE YourDB;
GRANT SELECT ON dbo.functionName TO UserName;
Voici comment j'ai pu résoudre le problème quand je l'ai affronté
Properties
.Membership
.Assurez-vous de décocher
db_denydatareader
db_denydatawriter
Cela devrait aller de soi, mais accordez uniquement les autorisations à ce dont l'utilisateur a besoin. Une solution facile paresseuse consiste à vérifier db_owner
comme je l’ai fait, mais ce n’est pas la meilleure pratique de sécurité.
Vérifiez l’espace de votre base de données. Cette erreur survient lorsque l’espace est augmenté par rapport à l’espace attribué à la base de données.
Accorder des autorisations pour cet utilisateur est nécessaire
Je résous mon problème en faisant cela. [REMARQUE IMPORTANTE: elle autorise des privilèges accrus (étendus) sur le compte particulier, éventuellement plus que nécessaire pour un scénario donné].
À l'aide de SSMS, je me suis assuré que l'utilisateur disposait d'autorisations de connexion sur la base de données et sur ReportServer.
Sur la base de données spécifique interrogée, sous les propriétés, j'ai mappé leurs informations d'identification et activé les autorisations publiques et du datareader. En outre, comme d’autres l’ont déclaré, j’ai veillé à ce qu’aucune boîte Denyread/Denywrite ne soit sélectionnée.
Je ne voulais pas activer la propriété de la base de données quand pour leurs rapports, car ils n'avaient besoin que de certaines autorisations.