SQL71501 SSDT references non résolues – schéma de comparaison

Ok, il y a un tas de messages à ce sujet, mais toutes les différentes versions du problème. Je n'ai pas trouvé de message avec ma version spécifique (quoique fondamentale) du problème. Tout d'abord, voici les étapes que j'ai suivies pour créer un projet de database dans Visual Studio 2012 (shell) avec SQL Server Data Tools (SSDT):

  • Créer un nouveau projet, projet SQL-> database
  • Faites un clic droit sur le projet, choisissez "Comparer le schéma"
  • Définir la source (instance SQL Server sur un server)
  • Définir la cible (projet de database locale – le projet en cours)
  • Exécutez le "Schema Compare"
  • Mettre à jour la cible

Cela me donne un projet de database peuplé de tous les objects dans la database du server SQL. Cependant, lors de la construction du projet, j'ai plus de 200 erreurs de references non résolues:

X- contient une reference non résolue à un object. Soit l'object n'existe pas, soit la reference est ambiguë car il peut faire reference à l'un des objects suivants: X, Y, Z

ET

X- a une reference non résolue à l'object

L'ajout d'une reference de database à Master réduit les erreurs à 127, et maintenant c'est plus gérable, mais cela n'est pas résolu. Cela n'affecte que 5 ou 10 objects sur 100. Voici quelques points à garder à l'esprit:

  1. Une seule database est utilisée dans les objects SQL Server (vues, etc.)

  2. Seulement 2 parties nommant ie (dbo.Table comme T)

  3. L'option "Activer la vérification Transact-SQL étendue pour les objects communs" n'est pas présente dans ma version de VS 2012, cette fonctionnalité a été supprimée par Microsoft et est déjà désactivée.

  4. J'ai couru la command line sqlpackage.exe et sqlpackage.exe créé un dacpac de la database, ceci a été alors ajouté en tant que reference de database.

Le projet de database ne sera toujours pas construit. Les erreurs ne concernent que certaines vues et procédures. Est-ce que quelqu'un a eu ce problème?

Ok, j'ai trouvé le problème …

Il y a des champs dans une table qui ont leurs noms remplis d'espaces, c'est-à-dire:

[Field1]

Les vues, procs, etc. qui font reference à ces champs n'utilisent bien entendu que la partie name sans padding, c'est-à-dire: Field1

Ce nom [Field1] est incorrect, le vrai nom est [Field1] Cela a provoqué la rupture du schéma.

La partie difficile est …. ils travaillent toujours dans SQL Server. Bien que SQL Server affiche ces noms de champs dans une requête avec des erreurs, il est toujours en mesure de traiter la requête avec succès! J'ai l'printing que certains parameters ont été désactivés côté server … Quoi qu'il en soit, SQL Server n'aurait jamais dû permettre à ces instructions de s'exécuter correctement et le problème aurait été détecté.