Discussion :

[JeanYvette]

Bonjour bonjour

J'ai un problème d'accès sur une fonction table d'un schéma B d'une instance SQL server. Cette fonction doit pouvoir avoir accès à la table t du schéma A de la même instance de SQL server.
Les deux owner de chaque schéma sont différents et ainsi, ma fonction n'accède pas à mon schéma A. Ça fait longtemps que je n'ai pas administré sous SQL server et les post que je trouve me perdent un peu.

Certains parlent de créer un certificat pour le raccrocher à l'utilisateur du schéma B, d'autres disent que sans même owner j'ai le droit de pleurer toutes les larmes de mon corps ect....

J'aurais besoin de vos avis, pour savoir selon quel est le meilleur choix à faire pour accéder à mes besoins

Bisous bisous

[Michel.Priori]

Bonjour JeanYvette,

La rupture dans la chaine des propriétaires est un truc qui vaut mieux contourner que d'essayer de résoudre.
Enfin ça dépend de si on est sur la même base ou pas.

Si les objets sont sur des bases distinctes voir ici : https://docs.microsoft.com/fr-fr/dot...-in-sql-server

Si les objets sont dans la même base :
* voir pourquoi tous les objets n'appartiennent pas au même propriétaire et résoudre le problème en définissant un propriétaire "universel"

La raison en est la suivante : les droits ne sont pas ré évalués dans le cas où les objets sous-jacent appartiennent au même proprio.
Ainsi si DEV est propriétaire d'une table et d'une vue, on peut tranquillement donner le droit SELECT sur la vue tout en mettant un DENY SELECT sur la table pour l'utilisateur TOM. Le deny n'est pas évalué lors de la consommation de la vue.
A l'inverse si la table appartient à DEV et que la vue appartient à DBO, le fait de donner le droit SELECT sur la vue ne suffit pas car on va ré-évaluer les droits lors de l'accès à la table. Si on n'a pas donné le droit SELECT sur la table alors on aura le droit de voir les colonnes de la vue mais pas les lignes de la table

Mon conseil : faire en sorte que DBO soit le propriétaire universel des objets de la base.

A+

[JeanYvette]

Salut salut

Merci pour ton expertise. On est sur la même instance et pas le même schéma (base ?).
La raison est simple, la création de ce nouveau schéma a été demandé ainsi que le fait de créer un nouvel utilisateur et la personne a donc mis ce nouvel utilisateur en propriétaire.

Je vais voir de faire ce que tu me conseille, je reviendrais si besoin

Bisous bisous

[Michel.Priori]

Bonsoir JeanYvette,

On est sur la même instance et pas le même schéma (base ?)

SQL server fait bien la différence entre la base et le schéma.
La base étant une limite fonctionnelle (backup, sécurité, options, ...)
Le schéma étant un espace de nom avec en prime un objet permettant de définir des droits "à valoir" sur les objets présents et futurs.

Donc il est important, surtout pour CETTE demande de bien savoir de quoi on parle.

[JeanYvette]

En effet, mais je sais aussi qu'il m'arrive de me mélanger les pinceaux et surtout que certains ne résonnent qu'en schéma du fait d'être habitué en Oracle.
Ici, on parlait bien de database

Finalement, ce qui a été fait, c'est de rajouter les utilisateurs manquants de la base B a la base A puis de les affecter en dbreader/dbwriter via le mapping de l'user. Ensuite les petits grant habituels qui vont bien

En totu cas merci de ton aide. N'ayant jamais administré, cette notion de chaining de propriétaire était pour moi que de l'abstrait avant. Ca m'a permis de me documenter plus au moins cette histoire

Bisous bisous

[SQLpro]

...
SQL server fait bien la différence entre la base et le schéma.
La base étant une limite fonctionnelle (backup, sécurité, options, ...)
Le schéma étant un espace de nom avec en prime un objet permettant de définir des droits "à valoir" sur les objets présents et futurs.

Plus exactement :

• la base est un espace physique de stockage
• le schéma est un espace logique de stockage

SQL Server est multibase et multi schéma.
Le "file group" (groupe de fichier) est un sous espace de stockage.

A +