<\/p>\n
Wenn Sie in Ihrer Datenbank externe Informationen über System, Hardware oder Software benötigen, so lassen sich diese unter VBA meist nur über umfangreiche API-Routinen gewinnen. Dabei gibt es mit dem Windows Management Instrumentarium, kurz WMI, eine Schnittstelle, die fast keine Wünsche offen lässt und Ihnen enorm viel Programmierarbeit abnehmen kann. Das ist Grund genug, diese Schnittstelle einmal genauer unter die Lupe zu nehmen.<\/b><\/p>\n
Beispieldatenbank<\/b><\/p>\n
Die Beispiele dieses Artikels finden Sie in der Datenbank 1409_WMI.mdb<\/b>.<\/p>\n
Wie funktioniert das WMI<\/b><\/p>\n
Windows bringt WMI als einen Service mit, der in der Systemverwaltung auf den Namen Windows-Verwaltungsinstrumentation<\/b> hört und automatisch gestartet wird. Wirklich aktiv wird es allerdings erst, wenn eine Anfrage an den Service gestellt wird.<\/p>\n
Dann findet man im Taskmanager den neuen Prozess WmiPrvSE.exe<\/b>, eine Datei, die aus dem Unterverzeichnis \\wbem<\/b> des Windows-Systemordners heraus gestartet wird. Der Prozess selbst verwaltet nur die Anfragen und hat deshalb den Namen WMI Provider Host<\/b>.<\/p>\n
Bei Anfragen entscheidet er, welche zusätzlichen Dlls zu laden sind, in denen die eigentlichen Funktionen zur Ermittlung der Systemkomponenten untergebracht sind. Diese Dlls sind die Provider<\/b>, also Datenlieferanten, und ebenfalls im \\wbem<\/b>-Verzeichnis beheimatet.<\/p>\n
Sie finden dort außerdem zahlreiche Dateien mit der Endung .mof<\/b>. Das sind Textdateien, die die Struktur jedes Providers beschreiben.<\/p>\n
Wir kommen noch darauf zu sprechen, wie eine Anfrage an den Service gestellt wird. Der Ablauf sieht schematisch danach jedenfalls so aus:<\/p>\n
Der gesamte Vorgang ist standardisiert, sodass es keine Rolle spielt, ob Sie Hardware- oder Software-Komponenten abfragen wollen – der Ablauf ist immer identisch. <\/p>\n
Da das WMI intern eine Datenbank über alle möglichen abfragbaren Objekte aufbaut, liegt es nahe, dass diese über einen SQL-Dialekt angesprochen werden kann. Das ist auch der Fall: Die Abfragesprache nennt sich WQL<\/b>. Damit ist es möglich, ein Abbild der WMI-Datenbank in das Datenmodell einer Access-Datenbank zu überführen. Die Lösung dazu finden Sie in der Beispieldatenbank zum Beitrag. Das Datenmodell sieht aus wie in Bild 1 und zeigt eine hierarchische Struktur. Um es zu erläutern und die Entsprechungen zur WMI-Datenbank deutlich zu machen, nehmen wir ein einfaches WQL-Beispiel zur Hand:<\/p>\n
![\"Analogie](\"..\/fileadmin\/_temp_\/2014_06\/pic_962_001.png\")
<\/p>\n
Bild 1: Analogie des WMI-Datenmodells unter Access<\/span><\/b><\/p>\n Analog zu einer Access-Abfrage handelt sich bei Caption<\/b> offenbar um ein Feld, das aus der Datenherkunft Win32_Printer<\/b> stammt. Gesucht werden hier alle Bezeichnungen der im System installierten Drucker. Win32_Printer<\/b> scheint demnach eine Tabelle oder selbst eine Abfrage zu sein. Tatsächlich trifft eher Letzteres zu. Was unter Access eine Tabelle oder Abfrage ist, nennt sich unter WMI allerdings Objektklasse. <\/p>\n WMI-Datenmodell<\/b><\/p>\n Welches ist aber die Datenbank, aus der die Objektabfrage stammt Um bei der Analogie zu bleiben, nehmen wir an dieser Stelle das Ergebnis der Routinen der Beispieldatenbank vorweg und verweisen auf Bild 2.<\/p>\n Bild 2: Root-Provider-Liste des WMI<\/span><\/b><\/p>\n Das ist der Inhalt der im vorherigen Bild dargestellten Tabelle tblWMIRoot<\/b>. Was unter Access als die aktuelle Datenbank CurrentDb<\/b> bekannt ist, wäre im WMI die Objektklasse root<\/b>.<\/p>\n Sie besteht aus einer Auflistung von Grundklassen, bestimmten Standardkategorien, auch Namespaces genannt, von denen der Provider CIMV2<\/b> der wichtigste ist. CIMV2<\/b> ist eine Abkürzung für Common Information Model<\/b> Version 2. root<\/b> wäre der Name der Datenbank, CIMV2<\/b> eine Abfrage auf die Tabelle der Root-Provider. Also sähe die Syntax der Abfrage Win32_Printer<\/b> eigentlich so aus:<\/p>\n Dass diese Abfrage unter WQL so nicht funktioniert, werden wir noch sehen. Wichtig ist hier zunächst das Prinzip.<\/p>\n Ließe man die Bedingung in der Abfrage weg, so käme man auf eine Liste aller CIMV2<\/b>-Klassen. In der Beispieldatenbank steht dafür die Tabelle tblWMIClasses<\/b>. Ihr Inhalt ist auszugsweise in Bild 3 zu begutachten. IDNamespace<\/b> ist ein Bezug zu ID<\/b> der Root-Klasse; hier die 5<\/b> für CIMV2<\/b>. Die Tabelle ist wiederum mit der Tabelle tblWMI-ClassesProps<\/b> verlinkt, indem deren Feld IDClass<\/b> mit der ID verknüpft und als Unterdatenblatt dargestellt wird. In tblWMIClassesProps<\/b> stehen die Eigenschaften der jeweiligen Klasse und damit eigentlich deren Feldnamen. In der Abbildung sind für die Klasse Win32_CurrentTime<\/b> (aktuelle Systemzeit) die Eigenschaftsfelder ausgeklappt. Wollte man etwa den Tag des aktuellen Datums abfragen, so wäre der Wert des Feldes Day<\/b> der Abfrage Win32_CurrentTime<\/b> zu ermitteln. <\/p>\n Bild 3: WMI-Objektklassen und die Eigenschaftsfelder einer Klasse<\/span><\/b><\/p>\n Das WMI abfragen<\/b><\/p>\n Schauen wir uns nun an, wie das Abfragen der Systemzeit unter VBA konkret realisiert werden kann. Grundsätzlich gibt es da zwei Wege, die beschritten werden können: eine Variante ohne und eine mit Verweis-Bibliothek. Zur verweislosen Lösung finden Sie nachfolgend zwei Routinen. <\/p>\n Sie können eine Instanz des WMI sehr einfach erhalten, indem Sie einen speziellen sogenannten Moniker-String an die VBA-Funktion GetObjekt<\/b> übergeben:<\/p>\n Sie erhalten damit jedoch nicht etwa die oberste Ebene der WMI-Datenbank, also root<\/b>, sondern bereits den CIMV2<\/b>-Provider. Denn der voll ausgeschriebene Moniker-String müsste so lauten:<\/p>\n WMI verwendet, wenn bestimmte Parameter im String weggelassen werden, automatisch Defaults. Zu diesen Defaults gehören der angesprochene Computer, die root<\/b>-Datenbank und der CIMV2<\/b>-Provider. Die Syntax des Moniker-Strings lautet genau genommen<\/p>\n Für Computer<\/b> können Sie einfach einen Punkt verwenden, wenn Sie das lokale System ansprechen wollen. Damit wird bereits deutlich, dass man über das WMI auch andere vernetzte Rechner abfragen kann, soweit die Berechtigungen dazu ausreichen! Für Computer<\/b> kann man also ebenfalls die IP-Nummer oder den Netzwerknamen des Rechners angeben:<\/p>\n WMI ist übrigens unsensibel, was Groß- und Kleinschreibung angeht. Meist ist es egal, wie Sie einen Ausdruck schreiben.<\/p>\n In der Routine TestWMIDate1<\/b> (s. Listing 1) aus dem Modul mdlWMI<\/b> wird also zunächst ein Objekt objWMI<\/b> gesetzt, das dem Klassenkatalog des Haupt-Providers CIMV2 <\/b>entspricht. In Analogie zu Access entspräche dieses Objekt erst einer Datenbank. Und diese kann wie unter Access über OpenRecordset<\/b> abgefragt werden, nur dass sich der Befehl hier ExecQuery<\/b> nennt. Im WQL-String werden also die Felder Day<\/b>, Month <\/b>und Year <\/b>des Providers Win32_CurrentTime<\/b> abgefragt.<\/p>\n Listing 1: Erste Variante zum Ermitteln von Datumsangaben über das WMI<\/span><\/b><\/p>\n Als Resultat bekommen Sie über diese Abfrage nicht ein Recordset, sondern ein WMI-ObjectSet<\/b>, das in der Routine der Variablen objSet<\/b> zugewiesen wird. Zwar kann ein Recordset viele Datensätze enthalten, doch in unserem Fall gibt es nun mal nur ein aktuelles Datum.<\/p>\n Das Resultat besteht also nur aus einem Datensatz (WMI-Objekt). Dieser Datensatz muss jetzt für die weitere Verwendung in einer weiteren Objektvariablen obj<\/b> gespeichert werden. Man erhält ihn über die Funktion ItemIndex<\/b>([Datensatznummer]) des ObjectSets<\/b>. Und schließlich lässt sich der Inhalt des Datensatzobjekts extrem einfach über die Anweisung GetObjectText_<\/b> ausgeben. Heraus kommt dabei etwa dies:<\/p>\n GetObjectText_<\/b> entspricht damit dem Pendant GetString<\/b> eines ADO-Recordsets.<\/p>\n Da sich das Ergebnis in dieser Form schlecht weiterverwenden lässt, zeigt die Prozedur TestWMIDate2<\/b> in Listing 2, wie man stattdessen die einzelnen Feldwerte des Datensatzes auslesen kann. Sie gleicht anfangs genau der besprochenen Routine, verwendet dann aber die Auflistung Properties_<\/b> des Datensatzobjekts, um die Eigenschaftswerte zurückzugeben. Sie werden als String zu einem Ergebnis zusammengesetzt, der das aktuelle Datum wiedergibt:<\/p>\n Listing 2: Zweite Variante zum Ermitteln von Datumsangaben über das WMI<\/span><\/b><\/p>\n Warum erst hier, werden Sie fragen Hätte man, wie in einer Access-Abfrage, nicht gleich den Datums-String zusammensetzen können<\/p>\n Aber das lässt WQL eben nicht zu. Im SQL-String können nur einzelne Felder angegeben, aber nicht weiteren Operationen unterzogen werden, und die Zuweisung an einen Alias-Namen ist ebenso unmöglich.<\/p>\n WQL-Syntax<\/b><\/p>\n Die anderen relevanten Unterschiede von WQL zu JET-SQL sollen nicht verschwiegen werden. Was etwa auch nicht geht, ist die Verknüpfung mehrerer Tabellen in der Abfrage per Joins<\/b>.<\/p>\n Zwar lassen sich Verknüpfungen zwischen Provider-Klassen auf etwas kompliziertere Weise auch herstellen, Erläuterungen dazu würden jedoch den Rahmen des Beitrags sprengen. Forschen Sie bei Interesse nach den WQL-Stichwörtern Associators Of<\/b> oder References Of<\/b>.<\/p>\n <\/p>\n Möglich hingegen sind Bedingungen per WHERE<\/b>-Statement und die Zusammensetzung von Bedingungen über OR <\/b>und AND<\/b>. Für unser Datumsbeispiel mit nur einem Ergebnisdatensatz macht eine bedingte Filterung keinen Sinn. Daher hier ein anderes Beispiel:<\/p>\n Hier wird nach der Bezeichnung von installierten Druckern gefragt, die erstens für die gemeinsame Verwendung freigegeben sind (Shared<\/b>) und außerdem den Ausdruck Epson<\/b> im Namen haben. Im Unterschied zu Jet-SQL ist beim LIKE<\/b>-Operator das Zeichen % statt * zu verwenden.<\/p>\n Ansonsten können in Bedingungen auch die üblichen Vergleichsoperatoren =, >, <, >=, <=, <> sowohl für numerische Werte wie für Text verwendet werden. Auch IS NULL <\/b>und IS NOT NULL <\/b>für die Unterscheidung von leeren Feldwerten lassen sich setzen:<\/p>\n Das ermittelt alle Drucker, bei denen ein Servername gesetzt ist, also etwa Netzwerkdrucker.<\/p>\n Alle weiteren Informationen zu WQL entnehmen Sie bitte der Referenz von Microsoft: WQL (SQL for WMI)<\/p>\n Geht es auch kürzer<\/b><\/p>\n Die bisher vorgestellten Routinen lassen sich noch weiter komprimieren. In TestWMIDate3 (s. Listing 3) wurde auf eine Abfrage per ExecQuery<\/b> verzichtet, weil der Provider für Win32_CurrentTime<\/b> bereits in den Moniker-String verfrachtet wurde. Das geht problemlos, und der Schritt über das ObjectSet <\/b>wird übersprungen. GetObject<\/b> gibt mit dieser Syntax nun direkt das Datensatzobjekt zurück!<\/p>\n Listing 3: Dritte Variante zum Ermitteln von Datumsangaben über das WMI<\/span><\/b><\/p>\n In der Prozedur TestWMIDate4<\/b> (s. Listing 4) wurde außerdem die Angabe von root\/cimv2 <\/b>weggelassen, da WMI diese Werte ohnehin als Default annimmt. Die Prozedur zeigt darüber hinaus, dass durch komplexe Verschachtelung der Objekte mit nur einer Code-Zeile zum Ergebnis zu kommen ist. In diesem Fall allerdings nur für das aktuelle Jahr. Für den kompletten Datums-String fällt uns keine einzeilige Lösung ein.<\/p>\n Listing 4: Vierte Variante zum Ermitteln von Datumsangaben über das WMI<\/span><\/b><\/p>\n Die Bibliothek Microsoft WMI Scripting Library<\/b><\/p>\n Kommen wir zur Programmvariante mit Verweis. Auch wenn anzustreben ist, das VBA-Projekt einer Access-Datenbank nicht mit Verweisen zu überfrachten, gibt es keinen triftigen Grund, vom Verweis auf das WMI abzusehen. Denn alle Versionen von Windows unterstützen die Bibliothek, und Kompatibilitätsprobleme müssen nicht befürchtet werden.<\/p>\n Sie setzen einen Verweis auf die Bibliothek, indem Sie im Verweise<\/b>-Dialog des VBA-Editors den Eintrag Microsoft WMI Scripting V 1.2 Library<\/b> anhaken. Die Versionsnummer kann sich eventuell unterscheiden. Im Objektkatalog finden Sie die Klassen der Bibliothek dann über die Combobox links oben, wenn Sie WbemScripting<\/b> auswählen. In der Beispieldatenbank ist für unser Datumsproblem natürlich auch die Verweisvariante enthalten, wiedergegeben in Listing 5.<\/p>\n Listing 5: Verwenden der WMI-Klassenobjekte zur Datumsbestimmung<\/span><\/b><\/p>\n Das Hauptobjekt objWMI<\/b>, welches wir zuvor über GetObject<\/b> und den Moniker-String erhielten, muss in der Verweislösung über einen Zwischenschritt bereitgestellt werden. Erst wird ein generelles WMI-Objekt SWbemLocator<\/b> per New<\/b>-Anweisung erzeugt. Die einzige Methode des Objekts ist die Funktion ConnectServer<\/b>, die dann ein Services-Object objWMI<\/b> zurückgibt.<\/p>\n Der Name der Funktion deutet schon an, dass nicht nur das lokale System angesprochen werden kann, sondern auch andere Rechner in Netz. Deshalb lassen sich optional neben dem Namen des Rechners oder dessen IP hier auch weitere Parameter übergeben, wie Benutzername, Passwort und Domain. Das ist dann sinnvoll, wenn man auf dem entfernten Rechner einen Account mit administrativen Rechten besitzt – nur dann lassen sich auch alle WMI-Provider auslesen. Dieser Teil ist im Listing oben auskommentiert. Der zusätzliche Parameter für die Domain oder Workgroup muss übrigens genau die Syntax haben, wie im Beispiel:<\/p>\n NTLM ist ein Kürzel für einen Login per Windows LAN Manager<\/b>. Die zusätzlichen Parameter dürfen nicht<\/b> angegeben werden, wenn man den lokalen Rechner selbst abfragen will! Es kommt andernfalls zu einer Fehlermeldung.<\/p>\n Sobald das Service-Objekt steht, sieht die Lösung nicht anders aus, wie in den Beispielen zuvor. über ExecQuery<\/b> wird die Anfrage ans WMI gestellt, das Antwortobjekt einer ObjectSet<\/b>-Variablen zugewiesen, der einzige Datensatz über ItemIndex<\/b> ermittelt und dessen Felder über die Properties_<\/b>-Auflistung ausgegeben.<\/p>\n Der einzige Unterschied besteht darin, dass die Objektvariablen dezidiert auf Klassentypen der WMI-Bibliothek gecastet sind. Das macht das Schreiben von Code nun einfacher, da die VBA-IntelliSense immer die Syntaxvervollständigung zu den Objekten anbietet.<\/p>\n Antwortobjekte und Eigenschaften enumerieren<\/b><\/p>\n Sollten Sie in Ihrer Datenbank von WMI-Anfragen häufiger Gebrauch machen wollen, so ist es sinnvoll, hierzu eine allgemeinere Routine einzubauen. Das Gerüst dafür zeigt Listing 6. <\/p>\n Listing 6: Allgemeine Routine zum Abfragen von WMI-Providern<\/span><\/b><\/p>\n Der Prozedur AskWMI<\/b> ist als Parameter nur der Name des WMI-Providers zu übergeben – etwa Win32_CurrentTime<\/b>. Optional kann die Ergebnismenge eingeschränkt werden, indem zusätzlich die Zahl der abzufragenden Felder in sFields<\/b> angegeben wird – etwa Day,Month,Year<\/b>. Damit wären wir beim altbekannten Beispiel:<\/p>\n Rufen Sie diese Zeile im VBA-Direktfenster auf. Der Ablauf in der Routine entspricht dem der Prozedur TestWMIDate5<\/b>. Neu ist hier eine For..Each<\/b>-Schleife, die die Objektdatensätze und innerhalb derer wiederum deren Properties<\/b> durchläuft. <\/p>\n Das Ergebnis überrascht etwas, denn die Datumsangaben werden doppelt ausgegeben. Was läuft hier falsch In der Routine selbst nichts. Die Annahme, die aktuelle Systemzeit könne nur einen Datensatz enthalten, trügte nämlich. Um dem auf die Schliche zu kommen, ist in der Prozedur zusätzlich ein Teil eingebaut, der den Namen des Antwortobjekts selbst ermittelt. In den Eigenschaften steht der ja nicht drin. Zu diesem Zweck lässt sich die Eigenschaft Path_ <\/b>eines WMI-Objekts missbrauchen. Ihr Wert besteht aus einem String, der die Herkunft des Objekts im WMI darstellt. In unserem Beispiel enthält Path_ <\/b>etwa<\/p>\n Außer dem Rechnernamen, root<\/b> und dem Haupt-Provider cimv2<\/b> steht dort auch noch die eigentliche Klasse Win32_LocalTime<\/b>. In der Routine AskWMI<\/b> wird per Textfunktionen dieser Klassenname extrahiert und das Ergebnis (sTmp<\/b>) ausgegeben, bevor die Eigenschaften enumeriert werden. Nun wird klar, weshalb zwei Objekte im Ergebnis stecken: Win32_LocalTime und Win32_UTCTime<\/b>! Die Werte der Eigenschaften beider Klassen unterscheiden sich jedoch in der Regel nicht.<\/p>\n Bei Win32_CurrentTime<\/b> handelt es sich um einen zusammengesetzten Provider, der zwei untergeordnete Klassen beherbergt. Wollen Sie nur einen Datensatz im Ergebnis, so fragen Sie einfach die Subklasse ab:<\/p>\n Und das wäre schließlich das Resultat:<\/p>\n Was kann mit dem WMI abgefragt werden<\/b><\/p>\n Allein im letzten Absatz wurde deutlich, dass man die Namen der WMI-Provider genau kennen muss, um zum richtigen Ergebnis zu kommen. Alle Informationen darüber, welche WMI-Provider es gibt und welche Eigenschaften sie haben, ist online bei Microsoft im Windows SDK unter diesem Link dokumentiert: WMI Providers.<\/p>\n Wahrscheinlich werden Sie erschlagen sein, nachdem Sie sich diese Dokumentation zu Gemüte geführt haben. Es existieren über Tausend Provider allein im Zweig CIMV2<\/b>, kategorisiert nach Systemabteilungen, wie Hardware, Software, OS. Hinzu kommen noch einige speziellere Provider, etwa zu Registry-Abfragen, Netzwerk oder System.<\/p>\n Damit Sie sich nicht immer erneut durch diese Dokumente wühlen müssen, wenn Sie auf der Suche nach einem passenden Provider sind, enthält die Beispieldatenbank einige Prozeduren, die alle Provider und deren Eigenschaftennamen in Tabellen abspeichern. Von diesem Unterfangen war eingangs bereits die Rede gewesen, und das Datenmodell wurde ebenfalls bereits dargestellt.<\/p>\n Die Prozedur im Modul mdlWMI<\/b>, die diesen Transfer übernimmt, nennt sich WMIClasses<\/b>. Sie hier zu erläutern, würde zu weit führen. Rufen Sie sie einfach im VBA-Direktfenster auf und warten Sie einige Zeit, bis darin ein OK<\/b> zu sehen ist.<\/p>\n Je nach der Geschwindigkeit Ihres Rechners kann es schon mal einige Minuten dauern. Rufen Sie anschließend noch die Prozedur CleanWMIClasses<\/b> auf, die die Datensätze um Dubletten bereinigt und Provider ohne Eigenschaften – das kommt vor – löscht.<\/p>\n Danach sind die drei Tabellen der Beispieldatenbank komplett gefüllt. Um eine Orientierung zu geben: bei uns fanden sich 14 Haupt-Provider (tblWMIRoot<\/b>), über 3.000 Klassen-Provider (tblWMIClasses<\/b>) und zu diesen 31.000 Eigenschaften (tblWMIClassesProps<\/b>).<\/p>\n Wozu diese Prozedur jeweils neu aufrufen, wenn doch Microsoft in der Dokumentation klar vorgibt, welche Provider es gibt Hierfür gibt es einen Grund: Einige Software installiert zusätzliche WMI-Provider, die dann im System verankert sind. Dies macht MS etwa bei den Office-Paketen.<\/p>\n Office 2007 installiert einen ganz neuen Zweig im WMI, der in der Tabelle tblWMIRoot<\/b> als Eintrag MSAPPS12<\/b> in Erscheinung tritt. Ein solcher MSAPPS12-Provider ist zum Beispiel die Klasse Win32_Access12ComAddin<\/b>. über diesem Provider lässt sich per WMI abfragen, welche Access-COM-Addins im System installiert und ob sie aktiviert sind:<\/p>\n Gleichzeitig macht dies klar, dass nicht alle Provider, die auf Ihrem System ermittelt wurden, auch auf anderen Rechnern funktionieren. Deshalb sollten Sie beim Einsatz eines Providers immer prüfen, ob auch eine Online-Dokumentation für ihn existiert. Für den Zweig CIMV2<\/b> und die Win32-Provider ist das immer der Fall – und diese lassen eigentlich keine Wünsche offen.<\/p>\n Performance<\/b><\/p>\n Grundsätzlich kann das WMI mit spezialisierten API-Routinen nicht mithalten. Zum einen erfordert der überbau zusätzliche Rechenzeit, zum anderen füllt WMI häufig alle Eigenschaftenfelder zu einem Objekt mit Werten, auch wenn diese gar nicht benötigt werden. Die Ermittlung dieser Eigenschaftswerte kostet erheblichen Rechenaufwand. Win32_Printer<\/b> etwa hat 86 Eigenschaftenfelder!<\/p>\n Das sind reichlich viele, wenn Sie lediglich die Namen der installierten Drucker erfahren möchten. Machen Sie es sich deshalb zur Angewohnheit, wirklich nur die Felder in die WQL-Abfrage zu nehmen, die Sie auch benötigen. In der Regel kommt das der Performance zugute. <\/p>\n Bei manchen Providern nützt leider auch das nichts. Um alle installierten Programme des Systems aufzulisten, wie dies über die Systemsteuerung möglich ist, könnten Sie den Provider Win32_Product<\/b> verwenden und das Feld Name abfragen. Eigentlich eine schöne Sache, würde WMI dafür nicht Minuten benötigen…<\/p>\n Abfragen leicht gemacht<\/b><\/p>\n Nur, um Ihnen einen überblick über die Vielfalt der WMI-Provider zu geben, wurden die drei Tabellen in der Beispieldatenbank allerdings nicht angelegt. Sie sind vielmehr die Basis für ein Abfrage-Tool, das in Gestalt des Formulars frmWMI<\/b> daherkommt (s. Bild 4). <\/p>\n Bild 4: Tool für beliebige Anfragen an das WMI (frmWMI)<\/span><\/b><\/p>\n Im Kombinationsfeld ganz oben wählen Sie den WMI Namespace<\/b> aus, also den Root-Provider, etwa CIMV2<\/b>. Diese Combobox ist einfach an die Tabelle tblWMI-Root<\/b> gebunden. Nach Aktualisierung der Combobox öffnet sich die nächste Combobox mit den WMI-Klassen, die für den Namespace verfügbar sind. Die Combobox ist an die Tabelle tblWMI-Classes<\/b> gebunden, der Inhalt wird jedoch mit der ID<\/b> des Namespaces gefiltert:<\/p>\n Wird eine WMI-Klasse aus der Liste gewählt, dann öffnet sich das dritte Kombinationsfeld mit den für diese Klasse möglichen Eigenschaftenfeldern. Das Steuerelement ist an die Tabelle tblWMIClassesProps<\/b> gebunden, gefiltert über die ID der Klasse:<\/p>\n Nun geht es weiter mit den Feldern, die Sie im Abfrageergebnis haben möchten. Wählen Sie jeweils eine Eigenschaft aus und klicken danach auf den Button mit dem Pluszeichen.<\/p>\n Im Textfeld Eigenschaften<\/b> werden dann die Felder kommasepariert aneinander gefügt. Sie können das Textfeld auch manuell bearbeiten oder mit dem (-)<\/b>-Button leeren.<\/p>\n Danach kann bereits der Button Ausführen<\/b> betätigt werden. Das WMI wird nun abgefragt und das Ergebnis als Liste im untersten Textfeld präsentiert. Im Beispiel sind das alle Netzwerkadapter des Systems, zu denen auch virtuelle, wie etwa die WAN-Miniports, gehören.<\/p>\n Im Formular ist jedoch noch ein Bedingungsfeld untergebracht, über welches das Resultat gefiltert werden kann. Die Bedingung PhysicalAdapter = True<\/b> müssen Sie manuell in das Bedingungsfeld setzen. Nach Ausführen der Abfrage sind nur noch die nicht-virtuellen Netzwerkadapter aufgeführt. Die Syntax der Bedingungszeile muss WQL-konform sein. <\/p>\n Sie haben damit ein Instrument, mit dem Sie die einzelnen WMI-Provider testen können, wobei nicht nur interessiert, ob die Felder das zurückgeben, was man erwartet, sondern auch, ob die Performance der Abfrage für Ihren angepeilten Verwendungszweck ausreicht. <\/p>\n Haben Sie eine brauchbare Anfrage zurechtgebastelt, dann können Sie daraus eine gesonderte Routine für Ihre Datenbank programmieren, wie in den Listings eingangs des Beitrags beschrieben. In diesem Zusammenhang sollte auf noch einige Probleme eingegangen werden, auf die Sie stoßen könnten. Die vom Ausführen<\/b>-Button ausgelöste Ereignisprozedur des Formulars ist nämlich etwas umfangreicher, als man erwarten würde. ähnlich, wie in der Prozedur AskWMI werden auch hier die Objekte und deren Eigenschaften in Schleifen enumeriert. Der Wert einer Eigenschaft wird jedoch einer Spezialbehandlung unterzogen (siehe Listing 7). Neben den Datentypen String, Integer, Long etc., kann ein Wert nämlich auch ein Array erhalten, welches etwa über Debug.Print<\/b> nicht als String ausgegeben werden kann. <\/p>\nSELECT Caption FROM Win32_Printer<\/pre>\n
![\"Root-Provider-Liste](\"..\/fileadmin\/_temp_\/2014_06\/pic_962_002.png\")
<\/p>\nSELECT * FROM root.CIMV2 _\r\n WHERE Name = ''Win32_Printer''<\/pre>\n
![\"WMI-Objektklassen](\"..\/fileadmin\/_temp_\/2014_06\/pic_962_003.png\")
<\/p>\nSet<\/span> objWMI = GetObject(\"winmgmts:\")<\/pre>\nGetObject(\"winmgmts:\/\/.\/root\/cimv2\")<\/pre>\n
winmgmts:\/\/[Computer]\/root\/[Provider]<\/pre>\n
winmgmts:\/\/192.168.0.2\/root\/cimv2\r\nwinmgmts:\/\/Harry2\/root\/cimv2<\/pre>\n
Sub <\/span>TestWMIDate1()\r\n Dim <\/span>objWMI As Object<\/span>\r\n Dim <\/span>objSet As Object<\/span>\r\n Dim <\/span>obj As Object<\/span>\r\n Set<\/span> objWMI = GetObject(\"winmgmts:\/\/.\/root\/cimv2\")\r\n Set<\/span> objSet<\/span> = objWMI.ExecQuery(\"SELECT Day, Month, Year FROM Win32_CurrentTime\")\r\n Set<\/span> obj = objSet.ItemIndex(0)\r\n Debug.Print<\/span> obj.GetObjectText_\r\nEnd Sub<\/span><\/pre>\ninstance of Win32_LocalTime\r\n{\r\n Day = 21;\r\n Month = 09;\r\n Year = 2014;\r\n};<\/pre>\nSub <\/span>TestWMIDate2()\r\n Dim <\/span>objWMI As Object<\/span>\r\n Dim <\/span>objSet As Object<\/span>\r\n Dim <\/span>obj As Object<\/span>\r\n Set<\/span> objWMI = GetObject(\"winmgmts:\/\/.\/root\/cimv2\")\r\n Set<\/span> objSet<\/span> = objWMI.ExecQuery (\"SELECT Day, Month, Year FROM Win32_CurrentTime\")\r\n Set<\/span> obj = objSet.ItemIndex(0)\r\n With<\/span> obj.Properties_\r\n Debug.Print<\/span> .Item(\"Day\") & \".\" & .Item(\"Month\") & \".\" & .Item(\"Year\")\r\n End With<\/span>\r\nEnd Sub<\/span><\/pre>\n21.09.2014<\/pre>\n
SELECT Day & ''.'' & Month & ''.'' & Year\r\nAS DatumAktuell FROM Win32_CurrentTime<\/pre>\n
SELECT Caption FROM Win32_Printer _\r\nWHERE Shared=True<\/span> _\r\nAND Name LIKE ''%Epson%''<\/pre>\nSELECT Caption FROM Win32_Printer _\r\nServerName IS NOT NULL<\/pre>\n
Sub <\/span>TestWMIDate3()\r\n Dim <\/span>obj As Object<\/span>\r\n Set<\/span> obj = GetObject(\"winmgmts:root\/cimv2:Win32_CurrentTime\")\r\n With<\/span> obj.Instances_.ItemIndex(0).Properties_\r\n Debug.Print<\/span> .Item(\"Day\") & _\r\n \".\" & .Item(\"Month\") & _\r\n \".\" & .Item(\"Year\")\r\n End With<\/span>\r\nEnd Sub<\/span><\/pre>\nSub <\/span>TestWMIDate4()\r\n Debug.Print<\/span> GetObject(\"winmgmts:Win32_CurrentTime\").Instances_.ItemIndex(0).Properties_(\"Year\")\r\nEnd Sub<\/span><\/pre>\nSub <\/span>TestWMIDate5()\r\n Dim <\/span>objLoc As <\/span>New<\/span> SWbemLocator\r\n Dim <\/span>objWMI As <\/span>SWbemServices\r\n Dim <\/span>objSet As <\/span>SWbemObjectSet<\/span>\r\n Dim <\/span>obj As <\/span>SWbemObject\r\n Set<\/span> objWMI = objLoc.ConnectServer (\"192.168.178.28\", \"root\/cimv2\")\r\n'' Set<\/span> objWMI = objLoc.ConnectServer(\"192.168.178.28\", \"root\\cimv2\", \"Benutzername\", _\r\n'' \"Password\", \"NTLMDomain:Domainname\")\r\n Set<\/span> objSet<\/span> = objWMI.ExecQuery(\"SELECT Day, Month, Year FROM Win32_CurrentTime\")\r\n Set<\/span> obj = objSet.ItemIndex(0)\r\n With<\/span> obj.Properties_\r\n Debug.Print<\/span> .Item(\"Day\") & \".\" & .Item(\"Month\") & \".\" & .Item(\"Year\")\r\n End With<\/span>\r\nEnd Sub<\/span><\/pre>\nNTLM:[DomainName]<\/pre>\n
Sub <\/span>AskWMI(sProvider As String<\/span>, Optional<\/span> sFields As String<\/span> =\"*\", _\r\n Optional<\/span> sRoot As String<\/span> = \"cimv2\")\r\n Dim <\/span>objLoc As <\/span>New<\/span> SWbemLocator\r\n Dim <\/span>objWMI As <\/span>SWbemServices\r\n Dim <\/span>objSet As <\/span>SWbemObjectSet<\/span>\r\n Dim <\/span>obj As <\/span>SWbemObject\r\n Dim <\/span>objProp As <\/span>SWbemProperty\r\n Dim <\/span>sTmp As String<\/span>\r\n Dim <\/span>n As Long<\/span>\r\n Set<\/span> objWMI = objLoc.ConnectServer(\".\", \"root\/\" & sRoot)\r\n Set<\/span> objSet<\/span> = objWMI.ExecQuery(\"SELECT \" & sFields & \" FROM \" & sProvider)\r\n For Each obj In objSet<\/span>\r\n sTmp = obj.Path_\r\n n = InStr<\/span>(1, sTmp, \":\")\r\n sTmp = Mid<\/span>(sTmp, n + 1)\r\n sTmp = Replace<\/span>(sTmp, \"=@\", \"\")\r\n sTmp = Replace<\/span>(sTmp, sProvider & \".\", \"\")\r\n Debug.Print<\/span> sTmp\r\n For Each objProp In obj.Properties_\r\n Debug.Print<\/span> objProp.Name, CStr(Nz(objProp.Value))\r\n Next<\/span> objProp\r\n Debug.Print<\/span>\r\n Next<\/span> obj\r\nEnd Sub<\/span><\/pre>\nAskWMI \"Win32_CurrentTime\", _\"Day, Month, Year\"<\/pre>\n
<\/font>Harry2\\root\\cimv2:Win32_LocalTime=@<\/pre>\n
AskWMI \"Win32_LocalTime\", _\"Day, Month, Year\"<\/pre>\n
Win32_LocalTime\r\nDay 21\r\nMonth 09\r\nYear 2014<\/pre>\n
AskWMI \"Win32_Access12ComAddin\",,\"MSAPPS12\"<\/pre>\n
![\"Tool](\"..\/fileadmin\/_temp_\/2014_06\/pic_962_004.png\")
<\/p>\nSet<\/span> cbClasses.Recordset = _\r\n CurrentDb.OpenRecordset(\"SELECT ID,Class FROM tblWMIClasses WHEREIDNamespace=\" _\r\n & cbNamespace.Value &\" ORDER BY Class\")<\/pre>\nSet<\/span> cbProperties.Recordset = _\r\n CurrentDb.OpenRecordset(\"SELECTIDClass, Property FROM tblWMIClassesProps WHEREIDClass=\" _\r\n & cbClasses.Value & \" ORDER BY Property\")<\/pre>\n For Each oObj In oSet<\/span>\r\n For n = 0 To UBound<\/span>(arrProps) - 1\r\n sProp = arrProps(n)\r\n sText = sText & sProp & \" = \"\r\n vValue = oObj.Properties_(sProp).Value\r\n If <\/span>Not<\/span> IsNull(vValue) Then<\/span>\r\n'' If oObj.Properties_(cbProperties.Value).IsArray Then\r\n If <\/span>IsArray(vValue) Then<\/span>\r\n sValue = \"{\"\r\n For i = 0 To UBound<\/span>(vValue)\r\n sValue = sValue & vValue(i) & \", \"\r\n Next<\/span> i\r\n sValue = Left<\/span>(sValue, Len<\/span>(sValue) - 2) & \"}\"\r\n Else<\/span>\r\n sValue = Nz(vValue)\r\n End If<\/span>\r\n End If<\/span>\r\n sText = sText & sValue &