Ich verwende seit vielen Jahren in meiner Access 2007 Datenbank einen Shell-Befehl. Auch nach Umstieg auf Windwos 10 funktionierte er noch. Nun habe ich die Datenbank in Access 2016 geöffnet und der Befehl wird nicht mehr ausgeführt.
Call Shell("S:\edi4all\edi4all.exe " & strpath, 1)
Programmaufrufe über Shell ohne Argumente an anderen Stellen funktionieren.
Die Variable ist als String deklariert, als Variant funktioniert es auch nicht. Ich kann mir das überhaupt nicht erklären und wäre sehr dankbar für einen Tipp.
Was steht denn konkret in strpath?
Wird denn das Programm aus dem VBA-Direktbereich ohne Parameterangabe gestartet?Shell "S:\edi4all\edi4all.exe", 1
Der Programmstart ohne Parameter funktioniert
Der Parameter beinhaltet einen Dateipfad, z.B. S:\Rechnungen\R18_00017.txt
... und im Dateipfad sind keine Leerzeichen und die Datei existiert auch? Im Zweifeldsfall würde ich das Argument einmal zwischen " setzen.
Shell "S:\edi4all\edi4all.exe " & Chr$(34) & strpath & Chr$(34), 1
Hallo,
Zitatder Befehl wird nicht mehr ausgeführt
Das kann ich mir schwer vorstellen. Entweder wird er ausgeführt oder es gibt eine Fehlermeldung.
Hast du die LZF unterdrückt?Wie lautet der vollständige Code?
.. hat leider nichts geändert.
Die Datei existiert und es sind keine Leerzeichen im Namen. Genau der gleiche Code funktioniert in Access 2007 problemlos.
Kann es sein, dass Verweise fehlen? "Microsoft Shell .." habe ich aktiviert
Laufzeitfehler werden angezeigt, ich habe nichts deaktiviert
Wenn ich folgenden Befehl in das Direktfenster eingebe, funktioniert er in Access 2007 und und Access 2016 nicht
call shell ("S:\edi4all\edi4all.exe S:\Rechnungen\R18_00322.txt",1)
Public Sub EDIRechnung(Nummer As String)
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strEDIName As String, strpath As String
gNummer = Nummer 'globale Variable
If MsgBox("EDIRechnung für " & gNummer & " wird erstellt", vbOKCancel) = vbCancel Then
Exit Sub
End If
'Pfad zur Speicherung der Textdatei
strpath = "S:\Rechnungen\" & Replace(gNummer, "/", "_") & ".txt"
'Export
DoCmd.OutputTo acOutputReport, "RechnungEDI_b", acFormatTXT, strpath
'Parameter für Name der EDI-Datei
strEDIName = Replace(gNummer, "/", "_")
'EDI-Datei wird erzeugt
Call Shell("S:\edi4all\edi4all.exe " & strpath, 1)
'Zeitverzögerung
Call modALLG.Pause(1)
'EDI-Versand für die Datei wird angestoßen
Call Shell("S:\edi4all\edidmp.exe versand " & strEDIName, 1)
'Name der EDI-Datei wird gespeichert für automatischen EDI-Upload
Set db = CurrentDb
Set rs = db.OpenRecordset("tmpEDI")
rs.AddNew
rs!rech_id = "put " & Chr(34) & "S:\edi4all\sendung\O??_" & Replace(gNummer, "/", "_") & ".edi" & Chr(34)
rs.Update
rs.Close
gNummer = ""
End Sub
Hallo,
siehe https://support.office.com/en-us/article/shell-function-ff2e4b1b-712d-4e34-aea6-6832eadd3c63
und lies dort die "Note" ...
Mit anderen Worten, ist es anzunehmen, dass Dein Prozess wie erwartet asynchron startet, die naiv veranschlagte Pausenzeit aber nicht ausreicht.
Für Deinen Zweck dürfte auch eher ein Verfahren wie Programm starten, warten, ExitCode bestimmen (http://vb-tec.de/xshell.htm) angemessen sein.
Ich befürchte, das ist nicht das Problem. In diesem Fall müsste doch der Aufruf im Direktfenster funktionieren, oder?
Ja. Und wenn er nicht funktioniert, muss auch eine Fehlermeldung erscheinen. Du kannst Shell ja auch als Funktion aufrufen und Dir das Ergebnis (die ProzessId) im Direktbereich ausgeben lassen. Sie sollte > 0 sein.
Weiterhin könnte es möglich sein, dass der Sandkastenmodus (https://support.office.com/de-de/article/aktivieren-oder-deaktivieren-des-sandkastenmodus-um-makros-zu-deaktivieren-8cc7bad8-38c2-4a7a-a604-43e9a7bbc4fb) aktiv ist und die Ausführung verhindert, was ich allerdings von VBA so nicht kenne (vielleicht hat sich aber in neuerem Access-Versionen eine Änderung eingeschlichen?).
Und teste den Aufruf auch einmal mit einer lokalen Datei in einem C:-Verzeichnis.
Hallo,
noch ein paar Tips:
Optionen/Sicherheitseinstellungen überprüfen und einstellen (Vertrauensürdige Speicherorte, Netzwerkdateien zulassen, Makros zulassen, ActiveX zulassen, usw.)
Windows-Zugriffsrechte für die Netzwerkverzeichnisse prüfen.
Zum Sandkastenmodus:
https://support.office.com/de-de/article/einf%C3%BChrung-in-die-sicherheit-von-access-2010-cae6d764-0318-4622-955f-68d9f186d6ca#__toc265079117
Als Nebentest: Access-Applikation als Administrator ausführen.
Ich habe leider eine Zei lang gebraucht, um alle Tipps abzuarbeiten.
Den Sandkostenmodus konnte ich in der Registry nicht finden, weil das Verzeichnis
\Software\Microsoft\Office\14.0\Access Connectivity Engine\Engines
bei mir nicht exisitert
sondern nur 12.0 und 16.0 - beide ohne das Unterverzeichnis Access Connectivity Engine
Wenn ich Shell als Funktion aufrufe bekomme ich ein Ergebnis >0, aber es passiert leider nichts
Der Aufruf mit einer lokalen Datei auf C: funktioniert auch nicht
Ich bin als Administrator angemeldet.
Die Sicherheitseinstellungen habe ich geprüft.
:'(
Hallo,
noch'n Versuch:
kopiere die exe- und die Datendatei in ein lokales Verzeichnis (z. B. c:\Temp) und passe die Pfade an.
(Oder vielleicht besser noch: in das DB-Verzeichnis kopieren)
Was passiert dann damit?
auf C: hat es auch nicht geklappt
Der Pfad S: ist auch das Datenbankverzeichnis
Kann es sein, dass der Export meines Berichts als txt-Datei unter ACCESS 2016 irgendwie verändert ist? Ich habe beide Exporte (Access 2007 und 2016 ausgedruckt und verglichen und keinen Unterscheid sehen können)
Öffne mal ein Kommandozeilenfester, wechsle in das Verzeichnis mit dem Export und versuche, die Umwandlung manuell vorzunehmen. Wenn das funktioniert, solltest Du in Access sicherstellen, dass das aktuelle Verzeichnis auch jenes ist, welche den Export beherbergt.
ChDrive "S"
ChDir "S:\Dein\Verzeichnis\Pad
Shell ...Und stelle auch einmal die Zeitverzögerung höher ein.
Wenn ich den Befehl direkt in der Eingabeaufforderung eingebe, funktioniert es - auch ohne Verzeichniswechsel
Kann es sein, dass Access 16 dieses neue Powershell verwendet ?
Wie gesagt, die Eingabe im Eingabefenster funktioniert - auch ohne vorherigen Laufwerks- und Pfadwechsel. Nur aus VBA heraus nicht. Die Verlängerung der Verzögerung ändert nichts :'(
Hallo,
nochmal, hast Du die Access 2016 Einstellungen für das Trust Center vollständig angepasst/eingestellt?
(Vertrauenswürdige Speicherorte im Netzwerk zulassen mit Unterordner dieses Speicherorts sind ebenfalls vertrauenswürdig,
Vertrauenswürdigkeit von Dokumenten in einem Netzwerk zulassen,
ActiveX-Einstellungen/Alle Steuerelemente ohne Einschränkungen ... aktivieren,
Alle Makros aktivieren)
Ja habe ich. Wie gesagt, andere Shell Befehle funktionieren ja auch. Ich habe jetzt eine neue Access 2010 Datenbank erstellt und alle Objekte importiert. Auch das hat nichts gebracht.
Hallo,
setz mal einen Haltepunkt an den Shell-Aufruf und schau, ob die Code-Abarbeitung überhaupt dorthin kommt.
Ja, alles ok, nur passiert leider nichts :'(
Hallo,
naja, so langsam gehen die Lichter aus...
Letzter Vorschlag:
schreib mal:
Msgbox shell ("S:\edi4all\edi4all.exe S:\Rechnungen\R18_00322.txt",1)
und berichte, ob eine MsgBox aufmacht und was sie dann anzeigt....
Die msgbox meldet "41356"
Ich habe dann mal folgende Zeilen in den Code eingefügt:
Debug.Print ("S:\edi4all\edi4all.exe " & strpath)
MsgBox Shell("S:\edi4all\edi4all.exe" & strpath, 1)
Der debug Befehl gibt den richtigen String zurück:
S:\edi4all\edi4all.exe S:\Rechnungen\R18_01284.txt
Die Msgbox provoziert einen Laufzeitfehler 53 "Datei nicht gefunden"
Hilft das weiter?
Zitat von: sonja am März 11, 2018, 19:47:07
Debug.Print ("S:\edi4all\edi4all.exe " & strpath)
MsgBox Shell("S:\edi4all\edi4all.exe" & strpath, 1)
Die Msgbox provoziert einen Laufzeitfehler 53 "Datei nicht gefunden"
Hilft das weiter?
da fehlt ein Leerzeichen bei der msgbox
Danke!
Ich bin wohl schon zu müde
Also, es wird auch hier eine fünfstellige Ziffer angezeigt ...
Hallo,
ja, und wie lautet die ??
Hallo
eine Zahl <> 0 sollte lt. Hilfe eigentlich eine positive programmausführung darstellen.
Ist dein Proggy u.U. ein Konsolenprogramm? Wenn ja könntest du versuchen eventuelle FM's in eine Textdatei umzuleiten.
'Path für die ErrorOut.txt anpassen
Shell("S:\edi4all\edi4all.exe " & strpath & " 2>S:\ErrorOut.txt", 1)
danach öffnest du mal diese ErrorOut.txt
oder per wscript.shell
debug.print createObject("Wscript.shell").exec("cmd.exe /c S:\edi4all\edi4all.exe " & strpath).stderr.readall
Danke für den Hinweis.
Ich habe beides probiert. Im ersten Fall bekomme ich beim Kompilieren einen Syntaxfehler
Im zweiteren geht kurz das Eingabeaufforderungs-Fenster auf - bleibt aber leer
Die 5stellige Ziffer, die die msgbox liefert ist immer unterschiedlich, heute 46132
Zitat von: sonja am März 13, 2018, 07:09:53Die 5stellige Ziffer, die die msgbox liefert ist immer unterschiedlich, heute 46132
Aus der Online-Hilfe zur Shell-Funktion (https://msdn.microsoft.com/de-de/vba/language-reference-vba/articles/shell-function):
ZitatFührt, wenn der Vorgang erfolgreich ist, ein ausführbares Programm aus und gibt ein Variant ( Double )-Objekt zurück, das für die Vorgangsnummer des Programms steht. Andernfalls wird Null zurückgegeben.
Also funktioniert es schon mal, dein Befehlszeilenprogramm aus Access zu starten. Wenn es nicht das tut, was es soll, liegt folglich das Problem bei der Übergabe der Befehlszeilenparameter an das Programm.
- Ist der Pfad zu der zu bearbeitenden Datei wirklich exakt so, wie hier im Forum dargestellt, oder sind da evtl. Leerzeichen im Pfad? Wenn ja, muss der Pfad in Anführungszeichen eingeschlossen werden.
- Stimmt der Dateiname genau?
- Erwartet dein Befehlszeilenprogramm evtl. noch weitere Parameter?
PS: Hast du denn schon probiert, das Befehlszeilenprogramm ausserhalb von Access für eine der erstellten Dateien aufzurufen?
Die Befehlszeile stimmt genau. Wie ich weiter oben schon erklärt habe funktioniert exakt der gleiche Code in Access 2007 seit Jahren fehlerfrei. Ich habe keinerlei Veränderungen vorgenommen, sondern nur die Datenbank in Access 2010 geöffnet. Die gesamte Umgebung (Betriebssystem etc) ist identisch. Beide Programmversionen laufen auf dem selben Rechner.
Die Befehlszeile funktioniert außerhalb von Access 2010 - sowohl in Access 2007 als auch direkt in der Eingabeaufforderung
Hallo,
meiner Meinung nach erlauben die Sicherheitseinstellungen von Access es nicht, Dateien über das Netzwerk auszuführen. Ich empfehle, das nochmal und vollständig unter Access-Optionen/Sicherheitscenter zu überprüfen.
Handelt es sich nun um A2010 oder A2016?
Hallo.
Also ich tendiere dazu Franz, dem Mann vom Bodensee, zustimmen.
Wie könnte das Problem eingegrenzt werden?
1. Das Programm ,,edi4all.exe" auf ein Lokales Laufwerk in einen lokalen Ordner verschieben und testen ob es von dort aus geht.
2. Ein anders Programm z.B. Notepad.exe in das Problemlaufwerk kopieren und schauen ob es von Access aus gestartet werden kann.
Da ich das Programm ,,edi4all.exe"nicht kenne habe ich mal gegoogelt und folgendes PDF gefunden:
www.edi4all.de/Leitfaden.pdf (siehe Seite 3)
Frithjof
Es handelt sich um ACESS 2016. Entschuldigung!
Ich habe die sicherheitseinstellungen wieder und wieder geprüft.
Folgender Befehl funktioniert ja auch:
call shell ("C:\Program Files (x86)\Microsoft Office\root\Office16\winword.exe S:\newsletter-online.docx")
Ich hatte ja auch schon das gesamte edi4all Programm von C: ausgeführt. Ohne Erfolg
Ich starte auch andere Anwendungen aus VBA, die auf S: liegen.
Mittlerweile bin ich verzweifelt :(
Hallo,
ZitatIch hatte ja auch schon das gesamte edi4all Programm von C: ausgeführt. Ohne Erfolg
Das ist aber jetzt neu... ??
Ansonsten liegt WinWord.exe in einem lokalen Verzeichnis, nicht im Netzwerk....
ZitatDas ist aber jetzt neu... ??
s. #12 und #13
hier ein Beispiel für einen Programmaufgruf auf S. der funktioniert
ChDrive "S"
ChDir "S:\Datenbank\WWSSchnittstelleSEKO"
Shell ("DatenbankanbindungSEKO.exe " & EAN)Ich hatte auch bei edi4all die Variante mir vorherigem Laufwerks- und Verzeichniswechsel probiert - ohne Erfolg
Hallo hab auch 2016 bei mir geht es so
https://www.myonlinetraininghub.com/vba-shell (https://www.myonlinetraininghub.com/vba-shell)
call shell ("""C:\Program Files (x86)\Microsoft Office\Office16\winword.exe"" ""C:\Users\Papa\Desktop\Microsoft Word-Dokument (neu) (2).docx""")
Gruß Frank
Hallo Frank,
das ändert auch nichts .. Danke für den Hinweis.
lg
sonja
Ich habe das Problem gelöst:
Die neue Access Version ruft das Programm über einen relativen Pfad aus anstatt mit dem Laufwerksbuchstaben
Ich übergabe in VBA den Pfad "S:/....", ACCESS macht daraus "//nas/ ..."
Ich habe allerdings nicht herausgefunden, wie ich ACCESS dazu bringe, wieder S: zu verwenden.
Hallo,
ZitatACCESS macht daraus "//nas/ ..."
Da ich nur A2010 habe, - verwendet A2016 jetzt automatisch UNC-Pfade?
Ich verwende die inzwischen nur noch, und ermittele sie mit diesem Code
#If VBA7 Then
Private Declare PtrSafe Function WNetGetConnection Lib "mpr.dll" Alias "WNetGetConnectionA" ( _
ByVal lpszLocalName As String, _
ByVal lpszRemoteName As String, _
cbRemoteName As Long) As Long
#Else
Private Declare Function WNetGetConnection Lib "mpr.dll" Alias "WNetGetConnectionA" ( _
ByVal lpszLocalName As String, _
ByVal lpszRemoteName As String, _
cbRemoteName As Long) As Long
#End If
Public Function UncPath( _
ByVal Path As String, _
Optional ByVal IgnoreErrors As Boolean = True) As String
'----------------------------------------------------------------------------------
' Author : Josef Pötzl
' Purpose : gibt den UNC-Pfad des übergebenen Pfades zurück
'----------------------------------------------------------------------------------
Dim UNC As String * 512
If Len(Path) = 1 Then Path = Path & ":"
If WNetGetConnection(Left$(Path, 2), UNC, Len(UNC)) Then
' API-Routine gibt Fehler zurück:
If IgnoreErrors Then
UncPath = Path
Else
Err.Raise 5 ' Invalid procedure call or argument
End If
Else
' Ergebnis zurückgeben:
UncPath = Left$(UNC, InStr(UNC, vbNullChar) - 1) & Mid$(Path, 3)
End If
End Function
Vielleicht kannst du damit auch was anfangen.
gruss ekkehard