web-dev-qa-db-fra.com

Vue indexée Référencer des objets sur deux schémas différents

Quand j'essaie de créer/modifier une vue pour créer un index comme celui-ci

CREATE UNIQUE CLUSTERED INDEX IDX_vSalPopulation
   ON sfdc.vSalPopulation (ID);

Je reçois le message d'erreur suivant

MSG 1938, niveau 16, état 1, l'indice de ligne 40 ne peut pas être créé sur la vue "VSALPOPULATION" car l'objet sous-jacent "YR_TRM_SBTRM_TABLE" a un propriétaire différent.

Quand je vérifie les tables, je vois que les tables appartiennent à différents schémas

exec sp_tables 'dbo.YR_TRM_SBTRM_TABLE'
exec sp_tables 'vSalPopulation'
TABLE_QUALIFIER     TABLE_OWNER       TABLE_NAME              TABLE_TYPE    REMARKS
MyDB                dbo               YR_TRM_SBTRM_TABLE      TABLE         NULL 
MyDB                sfdc              vSalPopulation          VIEW          NULL

La Documentation sur les vues indexées stipule que vous ne pouvez pas avoir une vue indexée qui fait référence à deux bases de données différentes.

  • La vue doit être créée en utilisant le WITH SCHEMABINDING option.
  • La vue doit ne référence que des tables de base qui sont dans la même base de données que la vue.
  • La vue ne peut pas référer d'autres vues. … etc

Cependant, j'ai la même base de données , mais deux schémas différents . Peut-être que le problème est en réalité le troisième requis. Bien que je ne référencez pas d'autres vues, il existe des fonctions. Peut-être que j'ai mal compris le message d'erreur. Autorisations? Donc, généralement, est-il possible d'avoir une vue indexée qui fait référence à des objets de deux schémas différents?

Une définition simplifiée de la vue qui me donne la même erreur ressemble à ceci

ALTER VIEW sfdc.vSalPopulation
   WITH SCHEMABINDING 
AS
SELECT DISTINCT
    ID
FROM dbo.CAN
INNER JOIN dbo.YR_TRM_SBTRM_TABLE YTS ON CAN.YR_CDE = YTS.YR_CDE
WHERE YTS.SBTRM_END_DTE > GETDATE()
2
wp78de

Je pense avoir trouvé la réponse ici . Fondamentalement, accordez une autorisation de subvention sur mon deuxième schéma à DBO:

ALTER AUTHORIZATION ON SCHEMA::sfdc TO dbo

Cela a donc vraiment à voir avec la propriété/autorisation plutôt que le schéma lui-même. Voir: https://www.sqlteam.com/articles/unSerStanding-the-ference-between-owners-and-schemas-in-sql-server

3
wp78de