6
votes

Projet de base de données VS 2010 - Erreur SQL03006

J'ai créé un nouveau projet de base de données SQL Server au sein de VS 2010, a importé les objets de base de données et les paramètres d'une base de données locale nommée "gestionnaires" et a reçu l'erreur suivante tout en essayant de créer le projet:

SQL03006: Vue: [DBO]. [VW_MLFUNDS] a une référence non résolue à l'objet [Directeurs]. [DBO]. [MLFunds].

Je ne sais pas pourquoi cette vue se qualifie pleinement d'une référence de table pour inclure le nom de la base de données réelle et je préférerais ne pas avoir à modifier le SQL, comme le code de quelqu'un d'autre et techniquement n'est pas incorrect. Mais je pense que cela qualifiant pleinement le nom de la table pour inclure le nom de la base de données confondre le compilateur VS, car il s'attend à [DBO]. [MLFUND], non [gestionnaires]. [DGO]. [MLFunds]. Comment mieux résoudre ce problème? Puis-je configurer une nouvelle variable / alias de nom de base de données quelque part? Ou devrais-je refacturer / modifier le SQL pour l'obtenir pour compiler? Merci d'avance.


0 commentaires

3 Réponses :


1
votes

Vous devez créer un autre projet de base de données pour la base de données [Directeurs] et avoir votre projet 'Référencier' l'autre projet. Vous pouvez le faire comme une simple étape inverse ingénieur sur la base de données [Directeurs] qui importera tous les objets de cette base de données dans un nouveau projet VSDB. Voir Utilisation de références dans des projets de base de données .


3 commentaires

Pourriez-vous clarifier cela pour moi? Je suis confondu par la nécessité d'une référence lorsque les deux objets (la table de base et la vue) résident dans la même base de données [gestionnaires].


Je pensais [géré] est une base de données différente. Si la vue qualifie explicitement le nom de la table avec le nom de la base de données, la définition de la vue est techniquement incorrecte , car le projet peut être déployé sous un nom de DB différent, et même la post-déploiement, il peut être restauré / copié / attaché / instantané sous une variété de noms et la vue serait invalide dans tous ces scénarios.


Je pense que la nappe complète de la table avec le nom de la base de données n'a été involontaire de la part du développeur d'origine et nous pouvons finir par modifier le script d'affichage pour supprimer la référence de nom de la base de données, mais le script Créer pour la vue s'exécutera sans erreur. Dans SSMS et, lorsqu'il est exécuté contre la base de données des gestionnaires, il reconnaîtra la référence explicite aux gestionnaires comme étant à elle-même. Je suis d'accord c'est le code bâclé mais j'essayais de ne pas gérer avec elle pour le moment, car il nécessitera des tests. C'est pourquoi j'essayais de comprendre s'il y a un moyen de contourner cela.



5
votes

En réalité, il semble que le code devra être modifié, car cela n'est pas pris en charge. Réponse trouvée dans ce post:

Utilisation des noms locaux en 3 parties dans les objets de programmabilité


1 commentaires

Si vous vous connectez à cela et que vous ne pouvez pas comprendre pourquoi vos scripts de comparaison sont toujours bombardement, assurez-vous de définir l'option "Variables SQLCMD" dans l'écran "Sélectionner un schéma de sélection / cible".



2
votes

J'avais la même erreur après avoir créé un projet et importer un DB. La question pour moi était que la référence de la table de la table incluait le nom pleinement qualifié, mais les champs sélectionnés ne l'ont pas; Comme suit

SELECT l.UserID, l.Email, m.DOB, ....
FROM Layout as l
LEFT OUTER JOIN masterUs as m


0 commentaires