{"id":55000282,"date":"2015-08-01T00:00:00","date_gmt":"2020-01-24T15:59:22","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=282"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Nuetzliche_Helferlein_per_VBScript","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Nuetzliche_Helferlein_per_VBScript.html","title":{"rendered":"Nützliche Helferlein per VBScript"},"content":{"rendered":"

Das Entwickeln von Access-Anwendungen ist das eine, der Umgang mit der Peripherie derselben das andere. So will Ihre Anwendung erst verteilt werden, oder Sie benötigen Systemaktionen, die sich unter Access nicht so ohne weiteres ausführen lassen. Dann könnten Ihnen möglicherweise extern gestartete Skripte weiterhelfen. Solche Skripte schauen wir uns in diesem Beitrag an.<\/p>\n

Beispieldatenbank<\/h2>\n

Die Beispiele dieses Artikels finden Sie in der Datenbank 1504_ScriptingDemo.zip<\/b> und den enthaltenen Dateien.<\/p>\n

Script-Sprachen<\/h2>\n

Wenn Sie sich nach Möglichkeiten umsehen, um abseits von Access- und VBA-Programmierung unter Windows Makros auszuführen, so bieten sich etwa Batch-Dateien<\/b> mit der Endung bat<\/b> oder cmd<\/b> an, die Kommandozeilenaktionen starten. Viel Freude werden Sie dabei wahrscheinlich nicht haben, da der Sprachumfang reichlich beschränkt ist und zudem die Kenntnis zahlreicher Kommandozeilenparameter erfordert. Erheblich ausgefeilter kommt da die Windows-Powershell<\/b> daher, über die sich fast alles realisieren lässt. Sie verlangt Ihnen jedoch noch mehr Einarbeitung ab, die zudem wegen des objektorientierten Ansatzes nicht gerade leicht fällt. <\/p>\n

So bleibt als leistungsfähiger Ausweg das standardmäßig unter Windows installierte Visual Basic Scripting<\/b>, kurz VBScript<\/b>. Das Gute an der Sache: Wenn Sie sich halbwegs mit VBA-Programmierung auskennen, so wird ihnen das Erstellen von VBScripten leicht von der Hand gehen, denn Syntax und Sprachumfang sind nahezu identisch. Auf einige Unterschiede gehen wir noch ein.<\/p>\n

VBScripte<\/h2>\n

VBScript-Dateien sind einfache Textdateien mit der Endung vbs<\/b>, die VBA-Code enthalten und von der Windows-Scripting-Engine<\/b> ausgeführt werden. Diese Dateiendung ist automatisch mit einem der beiden Script-Prozessoren wscript.exe<\/b> oder cscript.exe<\/b> verknüpft.<\/p>\n

Doppelklicken Sie also auf eine vbs<\/b>-Datei, so startet in der Regel die wscript.exe<\/b>, welche die Anweisungen dann abarbeitet. Dabei nimmt sich die Engine den Code zunächst genau unter die Lupe und testet ihn auf Syntaxfehler. Im Fehlerfall wird eine entsprechende Meldung geöffnet. Danach kompiliert sie ihn und startet die Prozedur. Aber auch dann, wenn die Syntax stimmt, kann es zu Fehlern etwa infolge falscher Parameter oder inkorrekter Objektansprache kommen. Dann ereignet sich ebenfalls eine Fehlermeldung und das Script wird an dieser Stelle abgebrochen.<\/p>\n

An dieser Stelle ein Hinweis: VBScript ist an sich noch kein Sicherheitsrisiko, arbeitet jedoch nicht in abgeschotteter Umgebung. Zwar können Windows-API-Funktionen nicht aufgerufen – hier ein Unterschied zu VBA -, dafür aber beliebige ActiveX-Komponenten erzeugt werden, die ihrerseits allerlei Unbill hervorzubringen imstande wären. Aus diesem Grund werden die Script-Engines von Administratoren zuweilen gesperrt und die Ausführung von vbs<\/b>-Dateien verhindert. Inzwischen kommt das immer seltener vor, denn über VBA-Programmierung, die ja Bestandteil von beliebigen Access-, Word- oder Excel-Dateien sein kann, sind noch viel mehr unheilvolle Aktionen möglich. Und diese Dateien werden ja auch nicht gesperrt.<\/p>\n

VBScripte erzeugen<\/h2>\n

Nicht einfacher, als das! Legen Sie eine neue Textdatei an und speichern sie unter der Endung vbs <\/b>ab. Schreiben Sie nur diese eine Zeile in sie:<\/p>\n

Msgbox \"Hallo! Bin ein VBScript!\"<\/pre>\n
Doppelklicken Sie auf die dergestalt modifizierte Datei, und schon werden Sie mit dem Meldungsfenster beglückt, wenn Scripting nicht auf Ihrem System deaktiviert ist.<\/p>\n
Die Tatsache, dass es sich nur um Textdateien handelt, eröffnet die Möglichkeit, Scripte auch aus Access heraus zu erstellen. Dazu wird der Code in eine String-Variable geschrieben und diese in das Dateisystem abgespeichert, wie etwa in der Prozedur in Listing 1. Der Variablen sScript<\/b> wird die Codezeile von oben zugewiesen und über die Open<\/b>-Anweisung eine Datei mit dem Namen test.vbs<\/b> angelegt, wobei als Pfad das Verzeichnis der Datenbank (CurrentProject.Path<\/b>) verwendet wird. Anschließend wird die vbs<\/b>-Datei über die Script-Engine (wscript.exe)<\/b> und die Shell<\/b>-Anweisung aufgerufen.<\/p>\n
Sub <\/span>CreateVBScript()\r\n     Dim <\/span>sScript As String<\/span>\r\n     Dim <\/span>sVBSFile as string\r\n     sVBSFile = CurrentProject.Path & \"\\test.vbs\"\r\n     sScript = \"Msgbox \"\"Ich bin ein VBScript!\"\"\"\r\n     Open sVBSFile For Binary As <\/span>#1\r\n     Put #1, , sScript\r\n     Close #1\r\n     DoEvents\r\n     Shell \"wscript.exe \" & sVBSFile\r\nEnd Sub<\/span><\/pre>\n
Listing 1: Aus VBA heraus erzeugte VBS-Datei<\/p>\n
Rufen Sie einfach die Prozedur CreateVBScript<\/b> aus dem VBA-Direktfenster heraus auf und überzeugen Sie sich vom Erfolg der Routine.<\/p>\n
Anwendungsfälle<\/h2>\n
Warum sollte man aus Access heraus ein VBScript<\/b> aufrufen Schließlich lässt sich ja über VBA dasselbe erreichen, wie über ein externes Skript. Das stimmt jedoch nicht immer. Manche Aufgaben können nur über administrative Rechte erledigt werden – etwa das Setzen von bestimmten Registry<\/b>-Schlüsseln. Und da Access nun Mal nur unter normalen Benutzerrechten ausgeführt wird, kann derlei nicht vollzogen werden. Von der Lösung, Access dennoch als Administrator auszuführen, sollten Sie besser die Finger lassen, weil dann die Add-Ins von Access und VBA durcheinander geraten können.<\/p>\n
Hier hilft ein VBScript<\/b> aus, das Aufgaben unter erhöhten Benutzerrechten ausführt. Den dafür benötigten Code schauen wir uns später an.<\/p>\n
Oft gebraucht wird ein Skript, das Ihre Datenbank überhaupt erst installiert. Nehmen wir an, Sie hätten alle Teile Ihrer Anwendung in einer Zip-Datei untergebracht. Da wäre es schön, wenn ein Script auf einem Zielrechner etwa folgende Aufgaben erledigen würde:<\/p>\n
Entpacken des Archivs; Anlegen von Zielverzeichnissen; Kopieren von Dateien in die Zielverzeichnisse; Setzen des Vertrauenswürdigen Orts für die Datenbank; Anlegen einer Verknüpfung auf dem Desktop; und eventuell noch das Registrieren benötigter ActiveX-Komponenten. Auch hierfür gibt es ein umfangreiches Beispiel-Skript, welches auf den folgenden Seiten erläutert wird.<\/p>\n
VBScript vs. VBA<\/h2>\n
Unter VBScript<\/b> brauchen Sie, wie wir weiter oben bereits gesehen haben, keine Prozedur zu deklarieren. Das Script selbst stellt schon eine Prozedur dar. Sie können gleich zu Beginn im Code mit der ersten Anweisung beginnen. Es ist Ihnen jedoch unbenommen, trotzdem Prozeduren auf die gleiche Weise anzulegen, wie unter VBA. Solche Sub<\/b>– oder Function<\/b>-Prozeduren sind dann sinnvoll, wenn sie als Unterroutinen im Code öfters aufgerufen werden.<\/p>\n
Variablen müssen unter VBScript<\/b> nicht deklariert werden. Dies kommt dem Verhalten von VBA gleich, wenn kein Option Explici<\/b>t im Modulkopf steht. VBScript<\/b>-Variablen sind immer vom Typ Variant<\/b>, was aber nicht bedeutet, dass ihr Sub-Typ nicht von Belang wäre. Funktionen etwa, die einen String als Parameter erwarten, kann kein Long-Wert übergeben werden. So eine Konversion nimmt VBS nicht automatisch vor.<\/p>\n
Wenn Sie es gewohnt sind, unter VBA in For..Next-Schleifen die Zählervariable namentlich einzusetzen, so müssen Sie unter VBScript davon Abstand nehmen.<\/p>\n
For i = 0 To 10\r\n...\r\nNext<\/span> i<\/pre>\n
führt zu einem VBScript-Syntaxfehler. Korrekt wäre<\/p>\n
For i = 0 To 10\r\n...\r\nNext<\/span><\/pre>\n
Darüber hinaus unterstützt VBScript<\/b> nicht die Deklaration von API<\/b>-Funktionen. Windows- oder andere DLLs können damit nicht angesprochen werden.<\/p>\n
Außerdem fehlt ausgerechnet eine ganze Reihe von Datei-Anweisungen, wie Dir<\/b>, FileCopy<\/b>, FileLen<\/b> oder FileDateTime<\/b>. Auch der Befehl Shell<\/b> zum Ausführen anderer Anwendungen existiert nicht. Solche Operationen müssen durch COM-Objekte ersetzt werden, die sich per CreateObject<\/b> erzeugen lassen. Die am häufigsten verwendeten Objekte sind das FileSystemObject<\/b>, das Shell<\/b>-Objekt aus shell32<\/b> und andere speziell für VBScript<\/b> entwickelte Komponenten, wie der Windows Scripting Host<\/b> (wshom.ocx<\/b>). All diesen Objekten begegnen Sie noch bei der Besprechung des Installations-Skripts.<\/p>\n
Zusammenfassend kann man feststellen, dass sich VBA-Code zu großen Teilen direkt in ein VBScript<\/b> übernehmen lässt. Entwickeln und debuggen Sie ihren Code unter VBA und ändern Sie ihn nach übernahme in ein VBScript<\/b> überall da, wo es notwendig ist.<\/p>\n
VBScripte debuggen<\/h2>\n
Leider ist der Komfort, wie Sie ihn von VBA her kennen, beim Debuggen von VBScripten nicht vorhanden.  Der Debugger zeigt lediglich eine Meldung an, wenn sich ein Fehler ereignet. Bild 1 ist ein Beispiel  für einen Syntaxfehler, Bild 2 eines für einen Fehler bei der Ansprache eines Objekts. Der Debugger zeigt immerhin die Code-Zeile und die Spalte an, in der sich der Fehler zutrug. Was genau dort schiefging, bleibt aber weitgehend verborgen. Eine Inspektion von Variablen oder Haltepunkte bleibt außen vor. Meist streut man dann diverse Message-Boxen in den Code ein, die die Werte von Variablen anzeigen, um dem Fehler auf die Schliche zu kommen. Wer viel mit vbs<\/b>-Dateien hantiert kann als Power User<\/b> zu Visual Studio <\/b>greifen, oder zu einem Tool, wie dem kostenpflichtigen VBSEdit<\/b> (http:\/\/www.vbsedit.com). Eine freie Alternative stellt der freie Admin Script Editor<\/b> (http:\/\/www.itninja.com\/community\/admin-script-editor ) dar. Diese können alle den Script-Code auf ähnliche Weise debuggen, wie VBA.<\/p>\n
\"Fehlermeldung<\/a><\/p>\n
Bild 1: Fehlermeldung der Script-Engine bei einem Syntaxfehler<\/p>\n
\"Fehlermeldung<\/a><\/p>\n
Bild 2: Fehlermeldung der Script-Engine bei einem Objektfehler<\/p>\n
Hilfsbibliotheken für VBScript<\/h2>\n
Wo Funktionen für bestimmte Aufgaben im Sprachumfang von VBScript<\/b> fehlen, greift man zu zusätzlichen Bibliotheken. Unter VBA tun Sie ja ähnliches, indem Sie zusätzliche Verweise<\/b> in das VBA-Projekt einklinken. VBScript<\/b> allerdings sieht das so nicht vor, kann aber fast alle Objekte erzeugen, die in der Registry unter dem Zweig HKEY_CLASSES_ROOT<\/b> zu finden sind. Also jene, die eine ProgId<\/b> aufweisen und durch einen mit Punkt getrennten Begriff gekennzeichnet sind, wie zum Beispiel Access.Application<\/b>.<\/p>\n
Die wichtigsten Aufgaben lassen sich mit zwei Bibliotheken erledigen, der Shell32<\/b>-Bibliothek und dem Windows Scripting Host<\/b>. Um sich über deren Inhalt zu informieren, laden Sie unter VBA Verweise auf die Bibliotheken Microsoft Shell Controls And Automation <\/b>(Shell32<\/b>) und Windows Script Host Object Model<\/b> (IWshRuntimeLibrary<\/b>) und inspizieren sie im VBA-Objektkatalog. Die Syntax für das Anlegen der wichtigsten Objekte unter VBA und VBScript<\/b> finden Sie hier im Vergleich:<\/p>\n
VBA:\r\nSet<\/span> oShell = New<\/span> Shell32.Shell\r\nSet<\/span> oShell2 = New<\/span> WshShell\r\nSet<\/span> fso = New<\/span> FileSystemObject\r\nVBScript:\r\nSet<\/span> oShell = CreateObject _\r\n   (\"Shell.Application)\r\nSet<\/span> oShell2 = CreateObject _\r\n   (\"WScript.Shell\")\r\nSet<\/span> fso = CreateObject _\r\n  (\"Scripting.FileSystemObject\")<\/pre>\n
über die so instanzierten Objekte lassen sich alle Aufgaben durchführen, die auch VBA ermöglicht. Das wären vor allem die Datei- und Verzeichnisoperationen über das FileSystemObject und das WshShell-Objekt. Aber auch die Registry lässt sich lesend und schreibend mit sehr einfachen Einzeilern ansprechen.<\/p>\n
öffnen Sie die Beispieldatenbank, in der die erwähnten Verweise bereits gesetzt sind. Im Modul mdlScripting<\/b> finden Sie verschiedene Prozeduren, die die Ansprache der Objekte verdeutlichen.<\/p>\n
Script als Administrator starten<\/h2>\n
Kommen wir nach den theoretischen Ausführungen zu einem praktischen Beispiel. Für viele Dateioperationen ist es notwendig, dass das ablaufende Skript Administratorrechte besitzt. Sei es, um Dateien in geschützte Verzeichnisse zu kopieren oder darin zu löschen, oder, um Rechte auf Ordner zu setzen. Doppelklicken Sie jedoch auf eine vbs<\/b>-Datei, so wird das Skript unter normalem Benutzerkontext gestartet. Im Prinzip müssten Sie die wscript.exe<\/b> Als Administrator ausführen<\/b> und ihr als Argument den Pfad der vbs<\/b>-Datei mitteilen. Das ist etwas umständlich. Mit einem Trick lässt sich das aber auch innerhalb der vbs<\/b>-Datei selbst bewerkstelligen. Nehmen Sie den Code des Beispielskripts setpermission.vbs<\/b> in Listing 2.<\/p>\n
Set<\/span> oShell = CreateObject(\"Shell.Application\")\r\nIf <\/span>(WScript.Arguments.Count = 1) Then<\/span> ElevateUAC\r\nSub <\/span>ElevateUAC\r\n      sCommand = WScript.Arguments(0)\r\n     'oShell.ShellExecute \"c:\\windows\\syswow64\\wscript.exe\", _\r\n    '    WScript.ScriptFullName & \" | \" & sCommand, , \"runas\", 1\r\n    '-> unter Winx64\r\n    oShell.ShellExecute \"c:\\windows\\system32\\wscript.exe\", _\r\n        WScript.ScriptFullName & \" | \" & sCommand, , \"runas\", 1\r\n    WScript.Quit\r\nEnd Sub<\/span>\r\nsFolder = WScript.Arguments(1)\r\nMsgbox \"Berechtigungen werden gesetzt auf \" & sFolder\r\noShell.ShellExecute \"Icacls.exe \", sFolder & \" \/grant Jeder:F \/T\", , \"open\", 1<\/pre>\n
Listing 2: Das Skript startet als Adminstrator und setzt dann Berechtigungen<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t