Der Import einer existierenden Datenbank in ein SQL Server Data Tools - Projekt ist zunächst ein einfacher Schritt, bei welchem es nicht viel zu beachten oder einzustellen gibt. Wird dann das erste lokale Build angestoßen, so ist ein häufiges Problem, dass sehr viele Meldungen in der Art .

Warning:  SQL71562: Procedure: [dbo].[MySP] has an unresolved reference to object [demo2].[dbo].[Employee]

. in der Errorlist zu sehen sind. In den allermeisten Fällen ist das Referenzieren von Objekten in einer anderen Datenbank, als der aktuell importierten, die Ursache. Diese Referenzen können (logischerweise) nicht vom Compiler aufgelöst werden, da diesem die andere Datenbank nicht bekannt ist.

Um diesen Umstand zu ändern, müssen wir dem Projekt eine Datenbank-Referenz hinzufügen. Dies kann auf zwei verschiedene Arten geschehen:

1. Erstellen/Hinzufügen eines weiteren DB-Projektes zu dieser Solution
2. Hinzufügen eines DACPACs zum Projekt

Die erste Methode kommt im Wesentlichen dann in Frage, wenn Sie die Struktur der anderen Datenbank auch wirklich in einem DB-Projekt verwalten möchten.

Methode 2 ist dann interessant, wenn es ausreichend ist, lediglich die Struktur der anderen DB bekannt zu machen, ohne dass man diese in der Solution verwalten und pflegen möchte. Dies ist häufig der Fall, wenn auf die andere DB lediglich zugegriffen wird, diese aber von einem anderen Team oder einer anderen Software bereitgestellt wird. Die folgende Vorgehensweise gilt für beide Methoden.

Eine DB-Referenz wird über das Kontextmenü des References-Knoten angelegt.

 Im daraufhin angezeigten Fenster wählen Sie die Art der Referenz aus.

Wenn Sie im Anschluss direkt mit "Ok" bestätigen, so werden Sie feststellen, dass die Warnungen nach wie vor vorhanden sind. Dies ist darin begründet, dass die Data Tools in der Standardeinstellung die Referenzierung über eine SQLCMD-Variable erwarten, was auch eigentlich die "sauberere" Variante ist, da der Name der zweiten DB jederzeit in den Projekteigenschaften auf der Seite "SQLCMD Variables" zentral geändert werden kann, ohne dass alle Referenzen angepasst werden müssen. In diesem Fall müssen Sie allerdings einmalig alle Codestellen, die auf die zweite DB verweisen, anpassen, so dass dort bspw. nicht mehr "Demo2.dbo.Tabellenname" referenziert wird, sondern die Syntax, so wie Sie in der folgenden Abbildung markiert ist, verwendet wird.

Alternativ zu der eben beschriebenen Vorgehensweise kann aber auch, wie in der nachfolgenden Abbildung markiert, vorgegangen werden. Hierdurch können alle Codestellen unverändert bleiben und die Buildfehler und -warnungen werden im Anschluss sofort nicht mehr auftreten. Wenn es unwahrscheinlich ist, dass sich der Name der zweiten Datenbank ändern wird, ist dies auf jeden Fall eine sinnvolle Alternative. Auch erhalten Sie sich mit dieser Variante den Vorteil, dass Sie Create-Scripts von Objekten, welche die andere DB referenzieren, direkt und einzeln ausführen können, um diese bspw. schnell auf einer DB einzuspielen und zu testen. Dies geht mit der ersten Methode nicht, da die Auflösung der SQLCMD-Variable nur im Rahmen eines Schema Compares oder zum Zeitpunkt des Publishings aufgelöst werden.