2015-03-11 1 views
0

Je convertis un modèle de base de données en un modèle SQL afin que nous puissions commencer à le déployer avec un dacpac. J'ai complété ceci avec quelques autres bases de données mais aucune référence des bases de données externes. J'ai un problème où un couple consulte des tables de référence de procédures stockées à partir d'une base de données différente qui se trouve sur le même serveur. Pour les procédures stockées, il n'y a pas d'erreur car les procédures n'ont pas besoin d'avoir les tables créées unitil runtime. Mais pour les vues, je reçois des erreurs de construction pourSQL Server Project Afficher les tables de références de différentes bases de données

contient une référence non résolue à un objet. Soit l'objet ne existe pas ou la référence est ambiguë

J'ai essayé de trouver un moyen de le faire fonctionner sans avoir à avoir un deuxième projet qui a les champs en place ou faire référence à un autre dacpac . Je collègue suggéré d'essayer des synonymes, mais cela n'a pas résolu le problème non plus.

Toute aide serait grandement appréciée.

+0

Les tables sur lesquelles les vues sont basées TSQL sont résolues lors de leur exécution (les tables répertoriées dans une procédure stockée ne doivent donc pas nécessairement exister au moment de la création) mais les tables/vues d'une vue est basé sur doit exister lorsqu'il est créé. –

+0

Ils existent dans une base de données externe sur la même instance que la vue est référençant la table comme EXTERNALDB.dbo.TABLE – greektreat

Répondre

0

Vous devrez créer des projets SQL supplémentaires et importer les autres dbo pour chaque référence de base de données externe. Ensuite, créez des références dans votre projet principal aux projets supplémentaires (ref externe). Vous devrez probablement trouver/remplacer toutes les références à trois niveaux dans votre base de données principale (maindb.schema.object -> schema.object) qui référencent également la base de données principale. ENFIN, construisez la solution et si elle est exempte d'erreurs vos erreurs de référence devraient disparaître.

Vous pouvez utiliser les codes d'erreur reportés (71561, 71501) pour chercher comment d'autres personnes ont résolu cela, mais les étapes ci-dessus ont fonctionné pour moi.

+0

Ya c'est ce que je prévois de faire si je ne peux pas comprendre cela d'une autre manière. J'ai été surpris qu'il n'y ait pas moyen de contourner cela. Je vais vous faire savoir ce que j'ai fini par faire. – greektreat

+0

Si vous trouvez quelque chose s'il vous plaît faire - notre architecture a des vues référencées externes dans les db externes, donc presque tous les projets dans ma solution ont des références! PITA! –

0

Je viens couru ceci sur deux bases de données (base de données locale et externe nommé x6 sur SQL Server 2012)

create view dbo.view1 
as 

select * from dbo.x5 inner join x6.dbo.t2 
on dbo.x5.i1 = x6.dbo.t2.x1 
; 
go 

create view dbo.view2 
as 

select * from dbo.x5 inner join x6.dbo.t2 
on dbo.x5.i1 = x6.dbo.t2 

View2 n'a pas été créé parce que je n'ai pas parlé à la colonne qui a été utilisée pour se joindre à la table x5 avec un message de:

L'identificateur en plusieurs parties "x6.dbo.t2" n'a pas pu être lié. Donc, cela a fonctionné quand j'étais explicite sur les colonnes utilisées pour se joindre. De plus, s'il y a des noms en double dans les deux tableaux, cela pourrait être confus.

S'il existe une colonne nommée state1 dans les deux tables et que vous sélectionnez un nom1 dans .... si vous obtenez une erreur de référence ambiguë.