Les utilisateurs ne peuvent pas afficher les tables dans un schéma non par défaut dans SSMS

Je rencontre un problème en définissant l' VIEW DEFINITIONautorisation de manière appropriée au niveau du schéma pour l'un de mes utilisateurs. J'ai créé le schéma TestSchemaet ajouté quelques tables. L'utilisateur dispose actuellement définir des autorisations d'accès et modifier la table ( SELECT, UPDATE, DELETE, etc.) à travers les dbo_datareaderet dbo_datawriterrôles. Cependant, ils ne peuvent voir aucune des tables dans l'explorateur d'objets SSMS.

J'ai essayé d'accorder des autorisations pour afficher les définitions:

grant view definition on SCHEMA :: [TestSchema] to [User]

Ça n'a pas marché. J'ai essayé de définir l'autorisation au niveau de la table:

grant view definition on [TestSchema].[NewTable] to [User]

Cela n'a pas fonctionné non plus. Ensuite, j'ai essayé juste une subvention globale:

grant view definition to [User]

Et cela a fonctionné; ils peuvent maintenant voir TestSchema, ainsi que d'autres schémas auxquels ils ne devraient pas avoir accès.

Mon objectif ici est de permettre à l'utilisateur de visualiser toutes les tables d'un schéma donné. Comment puis-je y parvenir? Si je devais être en mesure de le faire par défaut, quelles autorisations devrais-je consulter pour savoir pourquoi je ne peux pas?

Réponse courte: n'utilisez pas db_datareaderou db_datawriterou leurs équivalents de refus. Ils sont uniquement à des fins de compatibilité descendante. Leur utilisation entraînera des problèmes comme celui auquel vous êtes confronté.

Si vous souhaitez donner à Alice principale les autorisations SELECT, INSERT, UPDATE et DELETE sur tous les objets table dans le schéma Sales, utilisez ce qui suit.

GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::Sales TO Alice ;

Si vous souhaitez donner à Alice principale les autorisations SELECT, INSERT, UPDATE et DELETE sur tous les objets table dans tous les schémas, utilisez la procédure suivante.

GRANT SELECT, INSERT, UPDATE, DELETE TO Alice ;

La visibilité des métadonnées fonctionnera alors correctement.

Jetez un œil aux principales autres autorisations, il pourrait y avoir un refus quelque part à l'origine du problème. N'oubliez pas qu'un refus s'appliquera toujours en plus d'une subvention. Et comme ce n'est pas votre serveur, il pourrait y avoir quelque chose dans le compte que le département informatique a créé.

Utilisez quelque chose comme ça pour le niveau serveur:

    use master
    go
    SELECT a.*,b.name as 'Login ID' FROM sys.server_permissions as A inner join 
    sys.server_principals as B on a.grantee_principal_id = b.principal_id
    where b.name = 'login ID of the account'
    GO

Et quelque chose comme ça au niveau de la base de données

SELECT a.*,b.name as 'Login ID' FROM sys.database_permissions as A 
inner join sys.server_principals as B on a.grantee_principal_id = b.principal_id
where b.name = 'test'
GO

Cela m'est arrivé lorsque j'ai mis à niveau notre SQL Server de 2008R2 à 2014. db_datareader ou db_datawriter ou leurs équivalents de refus fonctionnent parfaitement en 2008R2 mais ils ne fonctionnent pas en 2014.

Exemple pour accorder une autorisation dans SQL Server 2014

Si vous souhaitez donner à l'utilisateur Alice les autorisations SELECT, INSERT, UPDATE et DELETE sur tous les objets table dans le schéma Sales, utilisez ce qui suit.

GRANT SELECT, INSÉRER, METTRE À JOUR, SUPPRIMER SUR SCHEMA :: Sales TO Alice; Si vous souhaitez donner à Alice principale les autorisations SELECT, INSERT, UPDATE et DELETE sur tous les objets table dans tous les schémas, utilisez la procédure suivante.

DONNER SÉLECTIONNER, INSÉRER, METTRE À JOUR, SUPPRIMER À Alice; La visibilité des métadonnées fonctionnera alors correctement.

Référence [Greenstone Walker].