Donnerstag, 30. Dezember 2010

Besitzer einer Datenbank ändern

Dieser Post ist mehr eine Gedächtnisstütze für mich selbst, da ich immer wieder vergesse, wie man den Besitzer einer Datenbank (oder allgemeiner: den Besitzer eines Objekts in SQL Server) ändert.
Ein Weg führt über die gespeicherte Prozedur sp_changedbowner, die aber als veraltet gekennzeichnet ist und nicht mehr verwendet werden sollte.
Der elegantere (und allgemeingültige) Befehl ist:
ALTER AUTHORIZATION ON ... TO ...

Die folgende Zeile ändert also den Besitzer der Datenbank DemoDB nach DemoLogin :

ALTER AUTHORIZATION ON DATABASE::DemoDB TO DemoLogin

Eine Auflistung aller Objekttypen und weitere Beispiele finden Sie in der SQL Server Dokumentation:
http://msdn.microsoft.com/de-de/library/ms187359(v=SQL.105).aspx

Montag, 6. Dezember 2010

UPDATE mit JOIN

SQL können wir wie ein Baukastensystem nutzen: Die Syntaxelemente lassen sich in vielfältiger Weise kombinieren, um die gewünschten Operationen auf unseren Daten auszuführen. Manchmal allerdings ist die Kombination etwas gewöhnungsbedürftig. Das UPDATE mit JOIN ist so eine spezielle, aber sehr nützliche Kombination.

Aufgabenstellung:
Es gibt eine Tabelle Artikel, die für jeden Artikel unter anderem eine Artikelnummer und einen Preis enthält.
Außerdem gibt es eine Tabelle NeuePreise, die neue Preise für einige Artikel enthält.
Nun sollen mit einem Update alle Artikel, für die es neue Preise gibt, aktualisiert werden.

Lösung:
Der folgende Code zeigt dieses Szenario. Das Update finden Sie am Ende des Codeabschnitts.

create table Artikel
(
  ArtikelNr int primary key,
  Name nvarchar(100),
  Preis decimal(7,2)
)
-- Wir tragen 3 Artikel ein:
insert into Artikel (ArtikelNr, Name, Preis) values
  (1, 'Artikel 1', NULL),
  (2, 'Artikel 2', 1.0),
  (3, 'Artikel 3', 30.0)

create table NeuePreise
(
  ArtikelNr int primary key,
  Preis decimal(7,2)
)
-- Jetzt geben wir für Artikel 1 und 2 jeweils einen neuen Preis an:
insert into NeuePreise (ArtikelNr, Preis) values
  (1, 10.0),
  (2, 20.0)

-- Ab hier aktualisieren wir die Preise
select * from Artikel  -- Daten vor dem Update
update a
  set a.Preis = n.Preis
  from Artikel as a inner join NeuePreise as n
    on a.ArtikelNr = n.ArtikelNr
select * from Artikel  -- Daten nach dem Update
 
Wie Sie sehen, wird erst ein Join zwischen Tabelle Artikel (a) und NeuePreise (n) gebildet. Diese Datenmenge enthält nur Datensätze, für die es neue Preise gibt (inner join). Für jeden dieser Datensätze wird nun das Update so durchgeführt, dass a.Preis den Wert von n.Preis erhält.
 
Eigentlich ganz einfach, oder?

Noch eine Anregung: Auf die gleiche Weise können Sie auch DELETE Anweisungen bauen.

Montag, 22. November 2010

Windows Server 2008 Aktivierung schlägt fehl - Fehlercode 0x8007232B

Diesen Eintrag sehe ich vor allem als Gedächtnisstütze für mich selbst, da ich inzwischen mehrfach an diesem Problem hängen geblieben bin. Aber vielleicht hilft es ja auch dem einen oder anderen Leser.

Problembeschreibung:
Nach erfolgreicher Installation einer Testmaschine mit einer MSDN-Lizenz tritt bei der Aktivierung folgender Fehler auf:

Lösung:
  1. Führen Sie ein Kommandozeilenfenster als Administrator aus.
  2. Geben Sie folgende Kommandozeile ein:
    slmgr -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
    Die xxxx-Zeichenkette steht für den Produktschlüssel.
Anschließend funktioniert die Aktivierung. Der genaue Hintergrund dieses Problems wird in der Microsoft Support Datenbank im Abschnitt "Methode 1" beschrieben.

Dienstag, 16. November 2010

Die Zukunft von SSAS

Auf der PASS Konferenz in Seattle vergangene Woche wurde die CTP 1 des nächsten SQL Servers "Denali" vorgestellt. Nun ist klar: Die Analysis Services werden ganz erheblich erweitert. Zusätzlich zum UDM (Unified Dimensional Model), mit dem wir zurzeit OLAP Cubes erstellen, wird es ein weiteres Modellierungskonzept geben: BISM (Business Intelligence Semantic Model).
BISM steckt unter der Haube von PowerPivot und soll Fachanwendern ohne fundierte IT-Kenntnisse ermöglichen, auf einfache Weise Analysedatenbanken zu erstellen. Und es ermöglicht natürlich auch IT-Fachleuten, mit weniger Aufwand zum Ziel zu kommen, als das mit UDM bisher der Fall ist.
Interessant finde ich, dass Microsoft im SQL Server Team Blog ausdrücklich beiden Entwicklungslinien eine gesicherte Zukunft bescheinigt.
Der SQL Server Team Blog Beitrag erklärt die Unterschiede, die Schnittstellen und die Zielgruppen von UDM und BISM.
Für uns heißt das auf jeden Fall mal wieder: Neues lernen.
Es bleibt spannend...

Freitag, 12. November 2010

XMLA Skript mit SSIS ausführen

Die Aufgabenstellung: Mit einem SSIS Paket soll ein XMLA Skript ausgeführt werden, um zum Beispiel eine neue Partition in einem Analysis Services Cube anzulegen.
Das Problem: Es gibt in SSIS keinen Task, der XMLA Skripte ausführt.
Die Lösung: Der "Execute SQL Task" leistet - trotz seines Namens - genau das Gewünschte.

Sehen Sie, wie es geht:
  1. Legen Sie einen ADO oder OLE DB Connection Manager an. Geben Sie als Provider "Analysis Services" an.
  2. In der Ablaufsteuerung fügen Sie einen "Execute SQL Task" hinzu.
  3. Wählen Sie als ConnectionType entsprechend dem vorher erstellten Connection Manager ADO oder OLE DB aus und wählen Sie unter Connection diesen Connection Manager aus.
  4. Lassen Sie SQLSourceType auf Direct Input stehen und geben Sie in SQLStatement das XMLA Skript ein (am besten das Skript mit Hilfe der Zwischenablage aus SQL Server Management Studio übertragen).  Ich habe als Beispiel ein kleines ClearCache Skript eingefügt.
  5. Starten Sie den Task (Rechtsklick auf den Task und im Kontextmenü "Execute Task" auswählen) - das war's schon!
Richtig interessant wird diese Möglichkeit, wenn Sie das XMLA Skript nicht direkt eingeben, sondern eine der beiden anderen Möglichkeiten von SQLSourceType nutzen:
  1. "File connection" ermöglicht Ihnen, das Skript aus einer Datei zu lesen.
  2. "Variable" holt das Skript aus einer Variablen. Mit Hilfe eines "Script Task" können Sie vorher das XMLA Skript in diese Variable schreiben.
Nachtrag: Mit dieser neu erworbenen "Freiheit des Denkens" ist mir dann aufgefallen, dass es noch eine zweite Möglichkeit gibt, XMLA Skripts in SSIS auszuführen: Der "Analysis Services Execute DDL Task" ist nämlich im Gegensatz zu seinem Namen nicht auf die Ausführung von DDL Statements beschränkt. Er kann (soweit ich sehen konnte) alle XMLA Befehle ausführen.

Montag, 25. Oktober 2010

Connection Pooling - eine Übersicht

Connection Pooling ist ein Thema, von dem ich eigentlich dachte, dass ich wüsste, worum es geht: Eine Anwendung schließt geöffnete SQL Server Verbindungen nicht vollständig, sondern legt sie nur schlafen. Auf diese Weise kann die nächste Verbindung schneller hergestellt werden.
So weit, so gut. Aber wie funktioniert das genau? Als ich jetzt in einem Projekt mit einer Reihe von Fragen zu diesem Thema konfrontiert wurde, musste ich feststellen, dass hinter diesem Konzept einige Details stehen, die mir nicht auf Anhieb klar waren. Ich habe die wichtigsten hier zusammengestellt:

  • Connection Pooling ist ein Feature des Clients (genauer: des Providers, s. u.), daher schweigt sich die SQL Server Dokumentation dazu auch aus ;-)
  • Es gibt einen Unterschied zwischen OLE DB Clients und ODBC Clients:
    • Bei OLE DB Clients erfolgt die Konfiguration des Connection Pooling über den Connection String (siehe unten).
    • Bei ODBC Clients erfolgt die Konfiguration über den Konfigurations-Dialog
 
  • In der .Open Methode eines Anwendungsprogramms prüft der Provider (= Datenbank-Treiber / Brücke zwischen Anwendung und Datenbank), ob bereits ein passender Connection Pool existiert.
  • Jeder Connection Pool ist bestimmt durch:
    • Connection String (alle Verbindungen in einem Connection Pool haben einen identischen Connection String)
    • Prozess (jeder Prozess macht seine eigenen Connection Pools auf)
    • Transaktionsebenen: Verbindungen, die innerhalb einer Transaktion geöffnet werden, werden einem neuen Pool zugeordnet.
  • Jede Anwendung kann beliebig viele Connection Pools öffnen – indem sie unterschiedliche Connection Strings verwendet.
  • Mit der .Open Methode wird entweder ein neuer Pool eröffnet oder eine Verbindung in einem bereits bestehenden wiederverwendet (Wiederverwendung ist das Ziel, um so die Kosten für den Verbindungsaufbau zu reduzieren.)
    • Wenn ein existierender Pool verwendet wird, sucht der Provider darin nach einer schlafenden Verbindung (dormant).
    • Falls keine schlafende Verbindung gefunden wird, erzeugt der Provider eine neue Verbindung und legt deren Handle in den Pool.
    • Wenn eine schlafende Verbindung gefunden wird, dann wird der Status der Verbindung bereinigt ("cleared"), d. h. der Status der Verbindung ist dann wieder so wie zu dem Zeitpunkt, wo sie erzeugt wurde.
    • Wenn der Prozess nach und nach mehr Verbindungen benötigt, dann wird das Erzeugen neuer Verbindungen wiederholt, bis 100 aktive Verbindungen (das ist die Default-Obergrenze) im Pool liegen.
  • Mit Aufrufen der .Close Methode durch die Anwendung wird die Verbindung als schlafend ("dormant") gekennzeichnet. Sie lieg dann bereit für die Wiederverwendung im Pool.
    • Wenn eine Verbindung länger als 4 bis 8 Minuten schlafend ist und nicht wiederverwendet wird, dann wird sie aus dem Pool gelöscht. Das wird so oft wiederholt, bis eine minimale Anzahl von Verbindungen (Standard: 0) erreicht ist.
    • Mit Beenden der Anwendung wird der Pool und alle darin enthaltenen Verbindungen gelöscht.
Das alles wird vom Provider durchgeführt. Das Verhalten bezüglich Connection Pooling wird über optionale Schlüsselworte im Connection String gesteuert:

Schlüsselwort: Pooling
Standardwert: True
Funktion: Pooling ein- oder ausschalten

Schlüsselwort: Min Pool Size
Standardwert: 0
Funktion: Untergrenze der Anzahl von Verbindungen, die ohne Rücksicht auf ihr Alter offen gehalten werden

Schlüsselwort: Max Pool Size
Standardwert: 100
Funktion: Maximale Anzahl von Verbindungen im Pool

Die typische Werte für die Anzahl aktiver und schlafender Verbindungen in einem Pool liegt - je nach Anwendung - im Bereich zwischen 10 und 20. Die Obergrenze von 100 sollte unter normalen Umständen nie erreicht werden.

Montag, 27. September 2010

Mehrspaltige Berichte mit Reporting Services

Mit SSRS können Sie Berichte erstellen, die mehrere Spalten haben (ähnlich einer Zeitungsseite):


Um das zu erreichen, bearbeiten Sie folgende Eigenschaften des Berichts:

  • Columns (Anzahl Spalten)

  • ColumnSpacing (Abstand zwischen den Spalten)
Dadurch wird im Design-Modus das Fenster folgendermaßen angezeigt:

Sie können Data Regions (Tabellen, Charts, etc.) nur in der ersten angezeigten Spalte hinzufügen - die anderen Spalten geben lediglich einen Eindruck, wie die fertige Seite aufgeteilt sein wird. Den Abstand zwischen den Spalten, die Seitenbreite und die Breite der einzelnen Spalte können Sie in dieser Ansicht direkt verändern. Genausogut können Sie aber auch die einzelnen Eigenschaften im Eigenschaftenfenster verändern.

Wenn Sie den Bericht testen, dann werden Sie jedoch (wie ich) vermutlich eine Enttäuschung erleben:
Einen mehrspaltigen Bericht sehen Sie nur dann, wenn das Ausgabeformat PDF oder TIFF ist!
Es gibt keine Möglichkeit, mehrspaltige Berichte in HTML zu generieren.

Weitere Informationen finden Sie hier in der Online-Dokumentation:
http://msdn.microsoft.com/de-de/library/ms159107.aspx

Mittwoch, 8. September 2010

LightSwitch - endlich ein würdiger Access-Nachfolger?

Von der serverseitigen Produktpalette rund um SQL Server und SharePoint bin ich wirklich begeistert. Aber wenn es um das einfache Erstellen von Eingabemasken für Daten geht, da klafft in der Microsoft Produktpalette eine schmerzliche Lücke. Sicher, ein erfahrener Entwickler kann mit Visual Studio sehr schnell Benutzeroberflächen erstellen. Aber was macht der engagierte Power-User ohne Kenntnisse in Software-Design? Hier erlebe ich drei Varianten:
  • Mit Visual Studio, Halbwissen und Enthusiasmus werden kleine Tools nach und nach zu "Business Critical" Anwendungen ausgebaut, bevor der Autor sich im Gewirr des Software-Entwicklungszyklus verheddert und sich frustriert von dem wackligen Gebilde abwendet.
  • Mit InfoPath werden zunächst einfachste Formulare erstellt. Wenn dann Anwender (verständlicherweise) individuellere Lösungen haben möchten, werden hoch qualifizierte Entwickler benötigt, die sich über weite Strecken mit seltsamen Effekten herumschlagen müssen.
  • Das gute alte Access wird einmal mehr wiederbelebt - trotz aller Probleme mit Versionierung, Softwareverteilung und Lastmanagement.
Die Lösung könnte bald LightSwitch heißen - ein neues Entwicklungswerkzeug, das sich zurzeit allerdings noch im Beta-Stadium befindet. Die aus meiner Sicht wichtigsten Merkmale sind:
  • vereinfachte Entwicklungsumgebung
  • vorgefertigte Entwurfsmuster
  • vordefinierte Datentypen mit Plausibilitätsprüfung bei der Eingabe
  • basiert auf den Microsoft Standard-Technologien .NET und Silverlight
  • Softwareentwickler können mit LightSwitch erstellte Anwendungen beliebig erweitern
Damit können wir schnell auf der Basis von vorhandenen Datenbanktabellen Formulare generieren und individuell anpassen - das war immer ein riesiger Vorteil von Access. Außerdem lassen sich auf einfache Weise Datenbanktabellen erzeugen, die im SQL Server liegen - das ist besser als mit Access.
Und das Beste: alles basiert auf .NET und Silverlight - damit ist das größte Manko von Access ausgeräumt.

Hier ist die Microsoft Produktseite:
http://www.microsoft.com/visualstudio/en-us/lightswitch
Und hier eine ausgesprochen informative Schritt-für-Schritt Anleitung von Jason Zander, dem Produktverantwortlichen:
http://blogs.msdn.com/b/jasonz/archive/2010/08/23/lightswitch-beta1-now-available-building-your-first-app.aspx

Ich werde mich in den nächsten Wochen mit der Beta näher auseinandersetzen und bin gespannt, welchen Verlauf die Entwicklung dieses viel versprechenden neuen Produkts nimmt.

Freitag, 3. September 2010

SQL Server Backups auf Netzwerk-Freigabe (UNC-Pfad)

Bei meinen Schulungen werde ich regelmäßig gefragt, ob SQL Server auch Sicherungen auf Netzwerk-Laufwerken erstellen kann. Hintergrund dieser Frage ist der Dialog im SQL Server Management Studio für das Erstellen von Backups. Dieser erweckt den Anschein, dass Netzwerklaufwerke kein Sicherungsziel sind, denn er bietet in der Auswahl nur lokale Laufwerke an.
Ein Netzwerkpfad lässt sich jedoch direkt eingeben, wie der folgende Screenshot zeigt:
Der Backup-Dialog sieht dann etwa so aus:
Noch klarer sieht man das im SQL Backup-Befehl:
BACKUP DATABASE [test] TO DISK = N'\\nbk1006\temp2\test.bak'


Damit das auch klappt, müssen allerdings drei Voraussetzungen gegeben sein:

  1. Der SQL Server muss auf einem Windows Server installiert sein, der Mitglied in einer Domäne ist.

  2. Der SQL Server Dienst muss mit einem Domänenkonto laufen.
    Hinweis: Ändern Sie das Dienstkonto immer nur mit dem "SQL Server Configuration Manager". Dann werden diesem Konto automatisch alle erforderlichen Berechtigungen zugewiesen (siehe hierzu auch http://msdn.microsoft.com/de-de/library/ms143504.aspx ).

  3. Das Domänenkonto muss auf der Netzwerkfreigabe (hier: \\nbk1006\temp2) Schreib- und Leseberechtigung haben.

Freitag, 20. August 2010

SSRS: My Reports Ordner fehlt

Laut Dokumentation gibt es die Möglichkeit, berechtigten Anwendern den Ordner "My Reports" zur Verfügung zu stellen. Dort haben sie dann die erforderliche Berechtigung, um nach Herzenslust eigene Berichte zu erstellen. Jeder Benutzer sieht seinen eigenen Ordner "My Reports", so dass der Datenschutz gewährleistet ist.
Das Problem ist nur: Es reicht nicht, einer Gruppe von Benutzern die Berechtigung hierfür zu erteilen, so wie nachfolgend dargestellt.

Bevor Ihre Anwender tatsächlich das erste Mal auf "My Reports" zugreifen können, müssen Sie als Administrator einmalig eine Einstellung vornehmen, die sehr gut versteckt ist:
Öffnen Sie mit SQL Server Management Studio eine Verbindung zu der richtigen SSRS Instanz. Achten Sie beim Herstellen der Verbindung darauf, dass Sie als Servertyp "Reporting Services" wählen, wie im Bild dargestellt.
Jetzt können Sie im Object Explorer mit der rechten Maustaste auf die SSRS-Instanz klicken und im Kontextmenü den Punkt "Properties" (Eigenschaften) auswählen. Das folgende Fenster öffnet sich:
Sehen Sie die unscheinbare Option "Enable a My Reports folder for each user"? Wenn Sie diesen Haken setzen und mit OK bestätigen, dann ist das Wunder vollbracht und die berechtigten Anwender sehen im Report Manger ihren My Reports Ordner!

Eigentlich ganz einfach, wenn man es weiß. Ob es in der nächsten Version von Report Manager vielleicht auch die Möglichkeit geben wird, das über die Web Anwendung einzustellen?

Donnerstag, 19. August 2010

Maps in SSRS - mehr als nur Landkarten

Die spektakulärste neue Data Region in Reporting Services 2008 R2 ist sicher die Landkarte ("Map"). Damit lassen sich zum Beispiel die Vertriebsstandorte in einer Landkarte darstellen und zu den Standorten zum Beispiel die Umsätze mit Symbolen wie Kreisen unterschiedlicher Größe und Farbe. Das ist schon ziemlich gut.
Hinter einer Landkarte steckt immer eine Beschreibung der Koordinaten mit Hilfe sphärischer Daten, also der Position auf der gerundeten Erdoberfläche.
Was mir bisher nicht so klar war, womit sich aber noch einmal ganz neue Einsatzgebiete für SSRS erschließen lassen: Genauso gut können Sie mit geometrischen Daten, also mit Koordinaten in einer Ebene, arbeiten.
Zum Beispiel beschreibt Hilmar Buchta hier die Erstellung von Shape-Dateien mit Visio. Auf diese Weise hat er einen Bericht erstellt, der die Verweildauer von Autos auf einzelnen Parkplätzen in einem Parkhaus mit Farben darstellt.
Sehr gut gefällt mir auch der Heatmap von Teo Lachev. Hier werden den Umsatzzahlen der einzelnen Geschäfte entsprechende Rechtecke zugewiesen.
Da bieten sich viele neue Möglichkeiten der Darstellung!

Deutsche Landkarten in SSRS anzeigen

Mit SQL Server 2008 R2 und Report Builder 3.0 ist es ja möglich, ortsbezogene Daten in Berichten darzustellen. Allerdings stellt Microsoft lediglich Karten der US-amerikanischen Bundesstaaten zur Verfügung.
Um in Deutschland lokalisierte Daten in einer Karte darzustellen, benötigt man ESRI-Shapefiles der deutschen Bundesländer. Wo man diese (kostenpflichtig und teilweise auch kostenfrei) bekommen kann, hat Tillmann Eitelberg in seinem sehr informativen Artikel dargestellt.

Freitag, 13. August 2010

SQL Server auf Windows Server 2008: Wie öffne ich die Firewall?

Bei der Installation von SQL Server 2008 (R2) auf einem der aktuellen Betriebssyteme gibt es diese Warnung:

Clients, die von anderen Rechnern aus versuchen, sich am SQL Server anzumelden, erhalten später folgende Meldung:
Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: Named Pipes-Provider, error: 40 - Verbindung mit SQL Server konnte nicht geöffnet werden)

Der Grund ist, dass die Firewall-Funktion von Windows die Maschine gegen die Außenwelt abschottet und nur solche Verbindungen durchlässt, die Sie in der Firewall freigeben. Es handelt sich also um eine ganz wichtige Sicherheitsfunktionalität. Daher erliegen Sie bitte nicht der Versuchung, einfach die ganze Windows Firewall zu deaktivieren – danach funktioniert zwar der Zugriff auf den SQL Server, aber Ihr Windows Server stünde dann "nackt" im Netz...

Die Funktionsweise der Windows Firewall ist so, dass jedes über das Netzwerk ankommende Nachrichtenpaket gegen einen Satz von Regeln geprüft wird. Gibt es eine Regel, die das Paket passieren lässt, funktioniert die Kommunikation. In unserem Fall brauchen wir also eine Regel, die den Zugriff von Clients auf den SQL Server zulässt.
Es gibt zwei unterschiedliche Werkzeuge zur Konfiguration von Regeln:
  • Das Kommandozeilentool netsh.exe
  • Die grafische Oberfläche des Betriebssystems, in diesem Fall ist das der Server Manager.
Der erste Weg ist zum Beispiel hier ausführlich beschrieben: http://support.microsoft.com/kb/839980/en-us

Ich erläutere nachfolgend den zweiten Weg mit Hilfe des Server Managers. Öffnen Sie hierfür den Server Manager ("Start" – "Administrative Tools" – "Server Manager") und öffnen Sie links unter "Configuration" den Knoten "Windows Firewall with Advanced Services".


Wir möchten eine Regel erstellen, die von außen Zugriffe auf den SQL Server erlaubt. Aus Sicht des Servers sind das eingehende Anfragen, also klicken Sie auf "Inbound Rules" – Regeln für eingehende Anfragen.
Sie sehen die bereits bestehenden Regeln. Ausgegraute Regeln sind zurzeit nicht aktiv.


Wir erstellen nun eine neue Regel. Klicken Sie hierzu mit der rechten Maustaste auf "Inbound Rules" und wählen Sie den Menüpunkt "New Rule…" aus.
Die erste Entscheidung, die zu treffen ist, betrifft die Art der Regel ("Rule Type"). Für unsere Aufgabenstellung kommen nur die ersten beiden Typen (Programm oder Port) in Frage. Was ist der Unterschied?



  • Port: Wir können zum Beispiel angeben, dass TCP Port 1433 für Anfragen von außen freigegeben wird. Das ist der Standard-Port für eine SQL Server Standard-Instanz. Wenn wir also bei der SQL Server Installation nichts Abweichendes angegeben haben, wird durch eine solche Regel die Standardinstanz von außen erreichbar.
    Das ist geradlinig und übersichtlich. Komplizierter wird die Sache, wenn Sie mehrere Instanzen von SQL Server installieren. Solange Sie daran denken, jeder Instanz einen festen Port zuzuteilen, können Sie für jede Instanz eine entsprechende Regel konfigurieren. Aber standardmäßig erhalten benannte Instanzen dynamisch beim Start einen Port zugeteilt – dann wissen Sie nicht, welchen Port Sie in der Firewall öffnen müssen.
    Hier kommt der Typ "Program" ins Spiel.

  • Program: Bei dieser Art von Regel können wir konfigurieren, dass einem Programm alle Netzwerkzugriffe erlaubt werden, die es benötigt. Wir geben nur den vollständigen Pfad der EXE-Datei an und das war's. Damit wird zum Beispiel das Problem der dynamisch zugewiesenen Ports gelöst.
    Nachteil: Da über eine Regel mehrere Ports geöffnet werden, kann die Fehlersuche aufwändig werden.
Sie können also frei entscheiden, welchen Typ Regel Sie erstellen möchten. Ich zeige Ihnen beide Wege. Fangen wir mit der Regel für den Port an:
  1. SQL Server benötigt normalerweise TCP Port 1433
  2. Die Regel soll den Zugriff erlauben ("Allow the connection")

  3. Die Frage nach dem Geltungsbereich der Regel benötigt noch eine Erklärung:
    Sie kennen diese Frage vielleicht von Windows 7, wenn Sie sich mit einem neuen Netzwerk verbinden, zum Beispiel mit dem WLAN zu Hause oder mit dem WLAN in einem Hotel. Dann stellt das System die Frage: "Was für eine Art von Netzwerk ist das?" Bei dem Netzwerk zu Hause (Private) haben Sie eine höhere Vertrauenswürdigkeit als in dem öffentlichen Netzwerk (Public). Innerhalb des Firmennetzwerks (Domain) können Sie die höchste Vertrauenswürdigkeit unterstellen. Dem entsprechend können Firewall Regeln abhängig gemacht werden von dem Netzwerk, in dem ein Rechner sich gerade befindet.

  4. Schließlich erhält die Regel noch einen Namen und eine Beschreibung:



    Das war die Konfiguration einer Regel für den Port.

Nun erstellen wir eine Regel für das Programm.

  1. Die Programmdatei sqlservr.exe befindet sich im Instanzverzeichnis im Unterverzeichnis BINN. Bei einer Installation mit den Default-Einstellungen ist das:
    %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe

  2. Die Verbindungen sollen zugelassen werden

  3. Erläuterung siehe oben

Vergeben Sie schließlich noch einen guten Namen und eine Beschreibung für die Regel
Das war die Konfiguration einer Regel für das Programm.

Weiter führende Informationen finden Sie zum Beispiel in diesem ausgezeichneten TechNet-Artikel: http://technet.microsoft.com/en-us/library/cc646023.aspx Hier wird unter anderem detailliert beschrieben, welche Ports für alle möglichen Konfigurationen freigeschaltet werden müssen, insbesondere auch für die Analysis Services, Integration Services und Reporting Services.

Nachtrag (23.06.2011)
Ein weiterer Port muss noch freigegeben werden: der UDP Port 1434! Dieser ist dann erforderlich, wenn Sie mit benannten Instanzen arbeiten. Über UDP Port 1434 fragen Clients an, welcher Port einer benannten Instanz zugeordnet ist. (Hintergrund: Da die Standardinstanz per Default TCP Port 1433 erhält und da jede Instanz einen anderen Port benötigt, haben benannte Instanzen einen anderen TCP Port als 1433.) Die Auflösung des Instanznamens zum Port übernimmt der SQL Server Browser Dienst. Daher muss dieser Dienst auch gestartet sein, wenn Sie mit benannten Instanzen arbeiten.
Nachdem Sie UDP Port 1434 freigegeben haben, werden Ihnen übrigens auch alle Instanzen im Auswahlmenü von SQL Server Management Studio angeboten :-)

Montag, 9. August 2010

Versionsverwirrung - Report Builder 3.0

Entgegen allen anders lautenden Hinweisen hatte ich das Problem, dass einige Funktionen, die im Report Designer (Visual Studio) enthalten waren, nicht im Report Builder 3.0 angeboten wurden. Dabei handelte es sich um die neuen Berichtselemente Data Bar, Sparkline, Gauge und Indicator.
Nach Deinstallation des Report Builder 3.0, Download der aktuellen Version und anschließender Neu-Installation waren die fehlenden Funktionen im Report Builder vorhanden.
Fazit: Es gibt anscheinend eine ältere Version von Report Builder 3.0, die sich in der Versionsnummer nicht unterscheidet, die aber dennoch nicht alle Funktionen der aktuellen Version enthält. Frage an Microsoft: Wäre es da nicht besser gewesen, einen Report Builder 3.1 zu veröffentlichen?