Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Fonction table avec accès sur multiples schémas avec owner différent


Sujet :

Administration SQL Server

  1. #1
    Membre averti
    Fonction table avec accès sur multiples schémas avec owner différent
    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

  2. #2
    Membre expérimenté
    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+
    Le savoir est une nourriture qui exige des efforts.

  3. #3
    Membre averti
    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

  4. #4
    Membre expérimenté
    Bonsoir JeanYvette,
    Citation Envoyé par JeanYvette Voir le message
    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.
    Le savoir est une nourriture qui exige des efforts.

  5. #5
    Membre averti
    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

  6. #6
    Rédacteur

    Citation Envoyé par Michel.Priori Voir le message
    ...
    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.