11
Batch Datei startet VBS mit Fehler
Hallo zusammen
seit kurzem, so wie es aussieht wurde auf unseren Firmen Netzwerk PC der Service Pack 2 bei Windows Professional bzw. auch bei Access habe ich schon Service Pack 2 bei den Infos gelesen.
Ich hatte bisher eine Batch Datei die eine VBS Datei gestartet hatte.
So und nun die Mitarbeitertool.vbs
Bei dieser VBS Datei kommt es seit dem Einspielung der Service Packs (vermutlich) zu einem Fehler in der Zeile 17. Komischerweise nicht bei jedem PC, aber bei der Mehrheit.
Zeile 17: WSHShell.OpenCurrentDatabase Link
Die VBS war damals dafür gedacht das die meheren Abfragen bevor die Access Anwendung gestartet wird umgangen wurden, damit der Mitarbeiter nicht verwirrt werden was sie nun drücken sollte, ob unsichere Ausdrücke blockieren oder nicht etc.
Wenn man in der Bat Datei statt der vbs die mde startet ist es ja auch o.k. aber dann bleibt das Dos Fenster auf und das verwirrt wieder.
Kann mir jemand helfen ?
Marja
seit kurzem, so wie es aussieht wurde auf unseren Firmen Netzwerk PC der Service Pack 2 bei Windows Professional bzw. auch bei Access habe ich schon Service Pack 2 bei den Infos gelesen.
Ich hatte bisher eine Batch Datei die eine VBS Datei gestartet hatte.
::mitarbeiter.bat
@echo off
if not exist F:\Desktop mkdir f:\Desktop
echo Es wird nun ?berprft ob eine neue Version existiert!
echo ...
echo Bitte warten Sie ! Das Mitarbeitertool wird gleich gestartet!
echo ...
copy G:\FM\Access\xxx\MitarbeiterTool\Desktop\Mitarbeitertool.lnk F:\Desktop/d
if not exist C:\Temp\%username%\Mitarbeitertool mkdir C:\Temp\%username%\Mitarbeitertool
replace G:\FM\Access\xxx\MitarbeiterTool\Desktop\Mitarbeitertool.mde C:\Temp\%username%\Mitarbeitertool/a
replace G:\FM\Access\xxx\MitarbeiterTool\Desktop\Mitarbeitertool.mde C:\Temp\%username%\Mitarbeitertool/u
replace G:\FM\Access\xxx\MitarbeiterTool\Desktop\Mitarbeitertool.vbs C:\Temp\%username%\Mitarbeitertool/a
replace G:\FM\Access\xxx\MitarbeiterTool\Desktop\Mitarbeitertool.vbs C:\Temp\%username%\Mitarbeitertool/u
C:\Temp\%username%\Mitarbeitertool\Mitarbeitertool.vbsOption Explicit
Const acCmdAppMaximize = 10
dim link
dim wshnetwork
dim wshshell
dim ingret
Set WshNetwork = WScript.CreateObject("WScript.Network")
Link = "C:\Temp\" &WshNetwork.UserName & "\Mitarbeitertool\Mitarbeitertool.mde"
Set WSHShell = WScript.CreateObject("Access.Application")
WSHShell.automationsecurity=1 ' low.
WSHShell.OpenCurrentDatabase Link
WSHShell.visible=true
WSHShell.RunCommand acCmdAppMaximize
WSHShell.docmd.Maximize
WSHShell.usercontrol=trueBei dieser VBS Datei kommt es seit dem Einspielung der Service Packs (vermutlich) zu einem Fehler in der Zeile 17. Komischerweise nicht bei jedem PC, aber bei der Mehrheit.
Zeile 17: WSHShell.OpenCurrentDatabase Link
Die VBS war damals dafür gedacht das die meheren Abfragen bevor die Access Anwendung gestartet wird umgangen wurden, damit der Mitarbeiter nicht verwirrt werden was sie nun drücken sollte, ob unsichere Ausdrücke blockieren oder nicht etc.
Wenn man in der Bat Datei statt der vbs die mde startet ist es ja auch o.k. aber dann bleibt das Dos Fenster auf und das verwirrt wieder.
Kann mir jemand helfen ?
Marja
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 27031
Url: https://administrator.de/contentid/27031
Printed on: April 18, 2024 at 02:04 o'clock
11 Comments
Latest comment
Moin Marja,
ich lese mir das nun auch zum dritten Mal durch, ohne eine richtig wahrscheinliche Erklärung für dieses Phänomen zu finden.
Ich denke, die ganz unwahrscheinlichen Gründe hast Du bestimmt schon selbst überprüft und ausgeschlossen (Leerzeichen im %username%; Fehlendes laufwerk F: ; keine Rechter auf C:\temp\; kein WSH/VBS installiert oder nicht erlaubt;...)
Hast Du denn
a) mal den inhalt von "Link" anzeigen lassen? Kommt da noch ein plausibler String raus?
b) was sagt denn in Fehlermeldung in Zeile 19 außer "Fehler"?
Gruß
Biber
ich lese mir das nun auch zum dritten Mal durch, ohne eine richtig wahrscheinliche Erklärung für dieses Phänomen zu finden.
Ich denke, die ganz unwahrscheinlichen Gründe hast Du bestimmt schon selbst überprüft und ausgeschlossen (Leerzeichen im %username%; Fehlendes laufwerk F: ; keine Rechter auf C:\temp\; kein WSH/VBS installiert oder nicht erlaubt;...)
Hast Du denn
a) mal den inhalt von "Link" anzeigen lassen? Kommt da noch ein plausibler String raus?
b) was sagt denn in Fehlermeldung in Zeile 19 außer "Fehler"?
Gruß
Biber
Hallo,
mir geht es genau so wie Biber.
Aber für den Übergang, bis das VBS wieder fehlerfrei läuft folgendes:
setze hinter die letzte Zeile der BAT ein eof oder ein exit oder auch ein cls.
MfG maneich
mir geht es genau so wie Biber.
Aber für den Übergang, bis das VBS wieder fehlerfrei läuft folgendes:
setze hinter die letzte Zeile der BAT ein eof oder ein exit oder auch ein cls.
MfG maneich
Vielen Dank für eure Antworten
Also komischerweise egal an welchen PC ich mich anmelde bekome ich nie die Fehlermeldung. Auf C:/Temp haben soweit alle Schreibrechte, anders ist es nachher bei der Backend Datei der Access Anwendung. Aber es hatte bisher alles funktioniert, ich schau mal ob ich nochmal an die Fehlermeldung rankomme.
Achso das cls oder exit oder eof funktionieren nicht so recht, da ja in der Batch Datei die mde geöffnet wird und erst wenn die Antwendung geschlossen ist, schließt sich auch das Dos Fenster.
Edit: Habe nun die Fehlermeldung
Script: C:\Temp\name.vorname\Mitarbeitertool\mitarbeitertool.vbs
Zeile: 17
Zeichen: 7
Fehler: Microsoft Office Access kann die Datenbank nicht öffnen, da sie nicht exisitert, oder da ein anderer Benutzer sie bereits im Exklusivmodus geöffnet hat.
Code: 800A1EBA
Quelle: (null)
hmm, was bedeutet das nun korrekt? Also vorher wie gesgat hat es wunderbar funktioniert.
Ablauf, für jeden Mitarbeiter wird beim Start der BAT die (Frontend) mitarbeitertool.mde auf dem Laufwerk C:/Temp unter dem Usernamen gespeichert, außerdem liegt da auch die mitarbeitertool.vbs. DIe Backend mitarbeitertool_back.mde liegt auf einem anderen NetzLaufwerk was für alle anderen aber zugänglich ist.
Hmm, was mich eigentlich nur stört ist das Dos Fenster was ständig offen bleibt, bei der vbs Variante wird dieses geschlossen.
Marja
Also komischerweise egal an welchen PC ich mich anmelde bekome ich nie die Fehlermeldung. Auf C:/Temp haben soweit alle Schreibrechte, anders ist es nachher bei der Backend Datei der Access Anwendung. Aber es hatte bisher alles funktioniert, ich schau mal ob ich nochmal an die Fehlermeldung rankomme.
Achso das cls oder exit oder eof funktionieren nicht so recht, da ja in der Batch Datei die mde geöffnet wird und erst wenn die Antwendung geschlossen ist, schließt sich auch das Dos Fenster.
Edit: Habe nun die Fehlermeldung
Script: C:\Temp\name.vorname\Mitarbeitertool\mitarbeitertool.vbs
Zeile: 17
Zeichen: 7
Fehler: Microsoft Office Access kann die Datenbank nicht öffnen, da sie nicht exisitert, oder da ein anderer Benutzer sie bereits im Exklusivmodus geöffnet hat.
Code: 800A1EBA
Quelle: (null)
hmm, was bedeutet das nun korrekt? Also vorher wie gesgat hat es wunderbar funktioniert.
Ablauf, für jeden Mitarbeiter wird beim Start der BAT die (Frontend) mitarbeitertool.mde auf dem Laufwerk C:/Temp unter dem Usernamen gespeichert, außerdem liegt da auch die mitarbeitertool.vbs. DIe Backend mitarbeitertool_back.mde liegt auf einem anderen NetzLaufwerk was für alle anderen aber zugänglich ist.
Hmm, was mich eigentlich nur stört ist das Dos Fenster was ständig offen bleibt, bei der vbs Variante wird dieses geschlossen.
Marja
Hallo,
nun, möglicherweise wurde mit dem Service-Pack 2 von Acces hier etwas dahingehend verändert, daß z.B. hier über VBS nicht mehrere User gleichzeitig auf das Object zugreifen können.
Die Frage ist, ob sich der Exclusivmodus umstellen läßt, ob es dafür einen Schalter oder Eintrag gibt. Dazu kenne ich aber Acces zu wenig.
Daß es mit cls, eof oder exit nicht klappt, habe ich mir fast gedacht. In den meisten Fällen startet die Batch ein Programm/Datei und springt dann zur nächsten Zeile ohne die Ausführung abzuwarten. Bei manchen Anwendungen klappt das aber nicht so, da hier die nächste Zeile erst ausgeführt wird, wenn der vorherige Aufruf abgearbeitet ist. Was hier der Fall zu sein scheint.
In einer VBS z.B. kann man eine Batch starten ohne daß sich ein Fenster öffnet mit
WSHShell.Run "%Comspec% /c Name.bat", 0
Wobei die 0 am Ende dafür sorgt, daß die Batch unsichtbar ausgeführt wird.
Ansonsten kannst du mal versuchen mit "On Error Resume Next" zu testen.
Dazu benötigst Du aber den Rückgabecode für fehlerfreie oder fehlerhafte Ausführung, den Du bekommst mit "x = WSHShell.OpenCurrentDatabase Link" und in der VBS z.B. mit
do
On Error Resume Next
x = WSHShell.OpenCurrentDatabase Link
Err.Clear
WScript.Sleep 1000
Loop Until x = ?
Damit bleibt das Script solange in der Schleife bis der Rückgabecode OK ist. Willst Du den Fehler abfragen dann mit "Loop Until not x = ?". Das klappt aber nicht bei allen Fehlermeldungen. Mußt eben mal testen.
MfG maneich
nun, möglicherweise wurde mit dem Service-Pack 2 von Acces hier etwas dahingehend verändert, daß z.B. hier über VBS nicht mehrere User gleichzeitig auf das Object zugreifen können.
Die Frage ist, ob sich der Exclusivmodus umstellen läßt, ob es dafür einen Schalter oder Eintrag gibt. Dazu kenne ich aber Acces zu wenig.
Daß es mit cls, eof oder exit nicht klappt, habe ich mir fast gedacht. In den meisten Fällen startet die Batch ein Programm/Datei und springt dann zur nächsten Zeile ohne die Ausführung abzuwarten. Bei manchen Anwendungen klappt das aber nicht so, da hier die nächste Zeile erst ausgeführt wird, wenn der vorherige Aufruf abgearbeitet ist. Was hier der Fall zu sein scheint.
In einer VBS z.B. kann man eine Batch starten ohne daß sich ein Fenster öffnet mit
WSHShell.Run "%Comspec% /c Name.bat", 0
Wobei die 0 am Ende dafür sorgt, daß die Batch unsichtbar ausgeführt wird.
Ansonsten kannst du mal versuchen mit "On Error Resume Next" zu testen.
Dazu benötigst Du aber den Rückgabecode für fehlerfreie oder fehlerhafte Ausführung, den Du bekommst mit "x = WSHShell.OpenCurrentDatabase Link" und in der VBS z.B. mit
do
On Error Resume Next
x = WSHShell.OpenCurrentDatabase Link
Err.Clear
WScript.Sleep 1000
Loop Until x = ?
Damit bleibt das Script solange in der Schleife bis der Rückgabecode OK ist. Willst Du den Fehler abfragen dann mit "Loop Until not x = ?". Das klappt aber nicht bei allen Fehlermeldungen. Mußt eben mal testen.
MfG maneich
Och menno,
da hätte ich auch gleich drauf kommen können...
Ändere bitte die Zeile:
WSHShell.OpenCurrentDatabase Link
-auf-
WSHShell.OpenCurrentDatabase Link, FALSE
...dann wird der exclusive-mode ausgeschaltet.
Syntax ist ja: OpenCurrentDatabase dbname[, exclusive].
Grüße
Biber
da hätte ich auch gleich drauf kommen können...
Ändere bitte die Zeile:
WSHShell.OpenCurrentDatabase Link
-auf-
WSHShell.OpenCurrentDatabase Link, FALSE
...dann wird der exclusive-mode ausgeschaltet.
Syntax ist ja: OpenCurrentDatabase dbname[, exclusive].
Grüße
Biber
Hallo Biber
leider ohne Erfolg bei einigen, selbst denen die keine Schreibrechte haben funktioniert es und bei manchen nicht.
Das mit der verdeckten Batch Datei, kann mir das einer vielleicht nochmal richtig erklären, also irgendwie bekomme ich das nicht hin, sorry
Marja
leider ohne Erfolg bei einigen, selbst denen die keine Schreibrechte haben funktioniert es und bei manchen nicht.
Das mit der verdeckten Batch Datei, kann mir das einer vielleicht nochmal richtig erklären, also irgendwie bekomme ich das nicht hin, sorry
Marja
Hm, Marja,
und die (unwahrscheinliche) Erklärung, dass es gar nicht an dem VBS-Schnipsel liegt, sondern tatsächlich irgendein User diese Datei manchmal exklusiv öffnet und alle anderen dadurch blockiert?
Gilt denn wenigstens für die User, die NICHT draufkommen, die eine Fehlermeldung bekommen, dass das reproduzierbar ist - auch nach Feierabend, wenn kein anderer User mehr mit der *.mde arbeitet?
Ratlos
Biber
und die (unwahrscheinliche) Erklärung, dass es gar nicht an dem VBS-Schnipsel liegt, sondern tatsächlich irgendein User diese Datei manchmal exklusiv öffnet und alle anderen dadurch blockiert?
Gilt denn wenigstens für die User, die NICHT draufkommen, die eine Fehlermeldung bekommen, dass das reproduzierbar ist - auch nach Feierabend, wenn kein anderer User mehr mit der *.mde arbeitet?
Ratlos
Biber
Hallo,
eine Batch über VBS zu starten ist einfach.
Du schreibst eine VBS z.B. start.vbs
Inhalt:
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "CMD.EXE /C Hier genau Adresse + Name.bat der Batch einfügen", 0
WScript.Quit
Beinhaltet die Adresse Leerzeichen dann in Doppelte Hochkomma einschließen.
WshShell.Run "CMD.EXE /C ""Hier genau Adresse + Name.bat der Batch einfügen""", 0
Das ist alles.
@Biber
Man lernt immer wieder etwas dazu; das mit der Angabe "false" war mir nicht bekannt.
MfG maneich
eine Batch über VBS zu starten ist einfach.
Du schreibst eine VBS z.B. start.vbs
Inhalt:
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "CMD.EXE /C Hier genau Adresse + Name.bat der Batch einfügen", 0
WScript.Quit
Beinhaltet die Adresse Leerzeichen dann in Doppelte Hochkomma einschließen.
WshShell.Run "CMD.EXE /C ""Hier genau Adresse + Name.bat der Batch einfügen""", 0
Das ist alles.
@Biber
Man lernt immer wieder etwas dazu; das mit der Angabe "false" war mir nicht bekannt.
MfG maneich
mmh das ist gar nicht so einfach, den wie gesagt bei mir klappt das an jedem PC, bei unterschiedlichen anderen Personen nicht, dadurch das dies auch noch ein Schichtbetrieb ist ist es schwierig eine Minuten zu finden wo keiner dieses Tool nutzt 
Vorher wie gesagt auch ohne Probleme erst durch das Office Update Service Paket.
Marja
Vorher wie gesagt auch ohne Probleme erst durch das Office Update Service Paket.
Marja
Hallo Maneich
würde es bedeuten:
WshShell.Run "CMD.EXE /C c:\blabla.bat", 0
??
Marja
würde es bedeuten:
WshShell.Run "CMD.EXE /C c:\blabla.bat", 0
??
Marja
Das liegt an dem SP2, da wird WSH in der Registry standardmäßig ausgeschaltet.
Kann dir die Keys aber zukommen lassen wenn noch benötigt.
Kann dir die Keys aber zukommen lassen wenn noch benötigt.
