Wie man grundsätzlich eine MPP Datenbank in Azure erstellt ist auf Simple Talk bereits gut beschrieben. Seitdem hat sich zwar vieles verändert, aber das grundlegende Erstellen passt nach wie vor.

Als Tools zum Arbeiten mit der Datawarehouse gibt die Möglichkeit über den SQL Server  Object-Explorer in Visual Studio zu arbeiten. Diese Variante wird aus der Weboberfläche von Azure auch angeboten („In Visual Studio öffnen“). Die Unterstützung für richtiges Arbeiten ist darin aber dürftig. Besser ist das schon vom on premise SQL Server bekannte Management Studio, dass von Microsoft kostenlos bezogen werden kann.

Man verbindet sich dabei mit dem zuvor festgelegten Servernamen. Nicht zu verwechseln mit dem Namen der Datenbank, die man innerhalb des Servers definiert hat. In meinem Fall ist das „jicazuredwh.database.windows.net“. Benutzername und Passwort sind während der Installation der Datenbank angelegt worden.

Unter Optionen verbirgt sich noch ein wichtiger Haken.

Die Checkbox suggeriert, dass es möglich wäre eine unverschlüsselte Verbindung zur Cloud aufzubauen. Gerade in einem Umfeld mit vielen Nutzern wäre dies fatal.

Mit dem Tool Whireshark lässt sich der Netzwerkverkehr  –  und eben auch die Anmeldung – mitprotokollieren. Auf die Anfrage des SQL Clients (Source) dass die Verschlüsselung möglich aber nicht notwendig aber möglich ist ….

…antwortet die Cloud, dass die Verschlüsselung für diesen Dienst sehr wohl notwendig ist. Unverschlüsselte Verbindungen sind nicht erlaubt.

Daraufhin beginnt der Client mit der Aushandlung (Hand-Shake) für die TLS-Transport-Verschlüsselung.

Die Erkenntnis, dass der Client zur Verschlüsselung gezwungen wird, lässt sich nun ebenso auf alle anderen Anwendungen übertragen. Ist also in deren Connection String die Verschlüsselung nicht explizit definiert, findet sich dennoch statt.

Zusätzlich zum Datenbankuser und Kennwort ist an dieser Stelle noch der Login über das Microsoft Konto notwendig. Über dieses Konto kann – wie im nächsten Screenshot zu sehen – die eigene IP (die IP des DSL/Mobilfunkanschlusses oder des Corporate Networks) zur Firewall hinzugefügt werden. Nur über diese IP(s) ist nun der Zugriff auf die Datenbank möglich.

Ab hier müsste die Verbindung klappen. Gelegentlich kann es noch zu Fehlermeldungen kommen (wie auch schon im Link von Simple Talk moniert), diese verschwinden aber bei einem zweiten Versuch.

The multi-part identifier „[Tabelle.Spalte]“ could not be bound.

Mit der Meldung hatte ich erst nicht viel anfangen können und habe mich also bei Google auf die Suche gemacht was das wohl ist. Gefunden habe ich dabei einen Artikel über den im SQL Server 2005 neuen Befehl „Apply“: Cross Apply auf MSSQLTipps

Das war zwar ein interessanter Exkurs über einen -für mich neuen- Operator, aber wohl nicht die Lösung meines Problems. Aber, meine Fehlermeldung taucht in dem Artikel auf, und hier dreht es sich wohl um die Definition des Joins.

Also nochmal zu meinem SQL , auf das nötigste reduziert :

select *
from tabelle1 tab1
join tabelle2 tab2 on tab1.fid = .tab2.fid
where tab1.name like 'a%' .....

Das Problem liegt hier in der Definition des Joins, hier hat einfach der Alias bzw der Spaltenname (in meinem Beispiel „.tab2.fid“ => „tab2.fid“).

Vielleicht findet ja nun der nächste mit dieser Fehlermeldung seine Lösung schneller als ich…