none
SQL-Server-Liste per SMO auf Client RRS feed

  • Frage

  • Hallo,

    in einem VS2010-Projekt hab ich Microsoft.SqlServer.Management.Smo eingebunden und hole mir per

    SmoApplication.EnumAvailableSqlServers()

    eine Liste der im Netzwerk zur Verfügung stehenden SQL-Server in eine DataTable. Die Angaben sind auch alle OK für den/die SQL-Server auf dem PC, auf dem ich mein Programm starte. Für andere SQL-Server im Netz wird aber immer fälschlicherweise "IsClustered" geflagt und die Version nicht zurückgeliefert. Ist das generell so oder ein Fehler, der nur bei mir auftritt?

    Ein anderes Ärgernis bezüglich der SMO-Assemblies: Es muss exakt die Version auf den ausführenden Rechnern installiert sein, die auch in VS in den Projektverweisen eingetragen ist; Vor- oder Rückwärtskompatibilität gibt es nicht. Schlimmer noch: Die Installation einer Version der SharedManagementObjects wird abgelehnt, wenn bereits eine neuere installiert ist. Das macht den Einsatz von SMO recht problematisch, vorallem, wenn man mit Systemen zu tun hat, auf denen schon andere SQL-Server-basierte Programme laufen. Oder hab nur ich das Problem hier?

    Gruß,

    WiWo

    Montag, 10. September 2012 21:29

Antworten

  • Hallo WiWo,

    zu 2) Es gibt kein Installationsproblem.
    Erstmal solltest Du zwischen Version und Release (Build) unterscheiden; ich hatte sie extra in fett dargestellt. Wenn SMO 2005 installiert ist, kannst Du problemlos SMO 2008 und dazu auch noch SMO 2012 installieren. Nur wenn davon ein bereits ein neueres Release installiert ist (z.B. aus neueren Service Pack), kannst Du kein älteres installieren.

    SQL Server Instanzen sind in der Tat separate Installationen mit separaten Verzeichnissen. SMO ist aber eine Shared Component, davon gibt es je Version nur eine Installation.

    Zu 1) Auf welchen Server im Netz SQL lauft wird per UDP Broadcast abgefragt, das darf so gerade jeder authentifizierter User. Die Details zu den Instanzen stehen in der Registry und die werden per Remote über WMI abgefragt und nein, das darf nicht jeder und ja, das sind Daten, die nicht jeder wissen sollen.

    Mal ganz ehrlich, Deine App geht so vor: Mal sehen, welche Server so laufen, und auf dem erst oder zweit besten lege ich die Datenbank an?

    Der beste Weg, Informationen über die SQL Server Infrastruktur zu bekommen, ist den SysAdmin / DBA zu fragen.


    Olaf Helper
    Blog Xing

    Dienstag, 11. September 2012 16:35

Alle Antworten

  • Hallo WiWo,

    das Abrufen der detailten Daten des SQL Server erfolgt per WMI und dafür brauchst Du auf den entsprechenden Zielrechnern, wo die SQL Server nun mal die Rechte dazu, die Daten abzufragen; fehlen die erhälst Du keine/nur Standardwerte zurückgeliefert. Es ist also generell so, es hängt von den Berechtigungen ab.

    Und das man keine älteren Releases einer Software installieren kann, wenn eine neuere Version vorhanden ist, ist ebenfalls generell immer so und das bei jeder Software.

    Es muss aber nur die gleiche Version wie die referenzierte sein, nicht das exakt gleiche Release.


    Olaf Helper
    Blog Xing

    Dienstag, 11. September 2012 05:25
  • Hallo Olaf,

    danke für Deine Antworten, aber leider hilft mir das noch nicht weiter.

    zunächst mal der 2. Punkt: Soweit ich bisher sehen konnte, besteht das Installationsproblem nur im Zusammenhang mit der Standalone-Installation einiger Komponenten aus dem SQL Server Feature Packs. Obwohl die immer in verschiedenen, versionsabhängigen Verzeichnissen installiert werden, lassen sich ältere nicht nach neueren Versionen installieren. Beim SQL-Server selbst geht das aber (oder irre ich mich?) und Microsoft dokumentiert auch die parallele Installation verschiedener Versionen.

    Das praktische Problem das ich damit habe: Verwende ich beispielsweise die SMO-Assemblies vom SQL-Server 2012 und installiere die, könnte nach mir niemand mehr ein ähnliches Programm installieren, das noch auf den SMO-Assemblies vom SQL-Server 2008 aufsetzt. Oder umgekehrt: Verwende ich die 2012er SMOs, liefe mein Programm nicht, wenn schon die 2012er installiert wären. Das ist doch ein unhaltbarer Zustand.

    ---

    zum 1. Punkt: Beim SMO-Aufruf zur Server-Auflistung gibt es natürlich keine Namens/Passwort-Übergabe. Aber die Server-Version dürfte eigentlich kein Betriebsgeheimnis darstellen. Möglicherweise treffe ich ja beim Kunden bereits installierte SQL-Server an und will sehen, welcher für mich geeignet ist. Wer die mal eingerichtet hat oder verwaltet, ist vielleicht jeweils nur mit Mühe rauszukriegen und deshalb will ich auch nur die Zugangsdaten erfragen von Servern, die für mich in Frage kommen. Die anzutreffenden Szenarien können beliebig kompliziert sein, und wenn ich da vielleicht erstmal nur eine Probe-Installtion machen will, kann ich nicht große Forderungen an saubere Grundlagen stellen.

    Kurzum: Gibt es vielleicht bessere Wege, um die SQL-Server-Infrastruktur (möglichst aus der eigenen Applikation heraus) von einem Client aus zu ermitteln? Ich stelle mir eine Erst-Einrichtung auf einem Client so vor:

    1. Ich kriege eine Liste aller SQL-Server im Netz. Wenn keiner oder kein passender dabei ist, muss natürlich erst einer eingerichtet werden.

    2. Wenn ein passender vorhanden: Einloggen in den Server. Ist meine Datenbank da schon drauf? Wenn nein, ggf. auf anderem Server nachsehen. Wenn ja, Einloggdaten verschlüsselt abspeichern und mit Ersteinrichtung fortfahren.

    3. Meine Datenbank existiert noch nicht, aber ein passender Server: Komplettes Einrichten der DB vom Client aus soll möglich sein.

    Gruß,

    WiWo

    Dienstag, 11. September 2012 08:56
  • Hallo WiWo,

    zu 2) Es gibt kein Installationsproblem.
    Erstmal solltest Du zwischen Version und Release (Build) unterscheiden; ich hatte sie extra in fett dargestellt. Wenn SMO 2005 installiert ist, kannst Du problemlos SMO 2008 und dazu auch noch SMO 2012 installieren. Nur wenn davon ein bereits ein neueres Release installiert ist (z.B. aus neueren Service Pack), kannst Du kein älteres installieren.

    SQL Server Instanzen sind in der Tat separate Installationen mit separaten Verzeichnissen. SMO ist aber eine Shared Component, davon gibt es je Version nur eine Installation.

    Zu 1) Auf welchen Server im Netz SQL lauft wird per UDP Broadcast abgefragt, das darf so gerade jeder authentifizierter User. Die Details zu den Instanzen stehen in der Registry und die werden per Remote über WMI abgefragt und nein, das darf nicht jeder und ja, das sind Daten, die nicht jeder wissen sollen.

    Mal ganz ehrlich, Deine App geht so vor: Mal sehen, welche Server so laufen, und auf dem erst oder zweit besten lege ich die Datenbank an?

    Der beste Weg, Informationen über die SQL Server Infrastruktur zu bekommen, ist den SysAdmin / DBA zu fragen.


    Olaf Helper
    Blog Xing

    Dienstag, 11. September 2012 16:35
  • Hallo WiWo,

    Ich gehe davon aus, dass die Antwort Dir weitergeholfen hat.
    Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

    Grüße,
    Robert


    Robert Breitenhofer, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Mittwoch, 26. September 2012 16:02
    Moderator