Excel Datei wird kann mit Funktion workbooks.open nicht geöffnet werden

[schmimla21 0]

Hallo zusammen,

 

bei uns soll mit folgendem (uralten) Code ein Excel-Sheet geöffnet werden und als eine gleichnamige csv-Datei im gleichen Netzwerkpfad abgespeichert werden. 

Option Explicit

main

sub main

  ' Deklaration der Variablen
  dim fso
  dim app
  dim xlsfile
  Dim csvfile 


  Set fso = CreateObject("Scripting.FileSystemObject")

  ' Abfrage der Kommandozeilenargumente
  If WScript.Arguments.Count <> 2 Then
      exit sub    
  End If

  on error goto 0

  xlsfile = WScript.Arguments(0)
  csvfile = WScript.Arguments(1)
  
  ' bestehende Dateien werden NICHT �berschrieben
  ' So wird gewährleistet dass bestehende Dateien zunächst verarbeitet werden
  if fso.FileExists (csvfile) Then
    exit sub
  end if
  
  set app = CreateObject("Excel.Application")
  WScript.echo "Excel started..."
  app.Workbooks.Open xlsfile, false, true
  app.ActiveWorkbook.SaveAs csvfile, 6,,,false,false,,,false,,,true
  app.ActiveWorkbook.Close false
  WScript.echo "Workbook closed..."
  app.Quit
  WScript.echo "Excel closed..."

End Sub ' main

Die weiteren Einzelheiten, wie und warum das Script aufgerufen wird, spare ich an dieser Stelle zunächst mal aus. Ich habe den Code nicht erstellt und habe auch keine Ahnung :)

 

Das Ganze dient letztendlich dazu, Werte aus diesem generierten .csv-File über eine Schnittstelle in eine Datenbank zu schreiben. Dies lief bislang auf einem System mit Windows Server 2008R2 und darauf installiertem Excel 2010 problemlos. Allerdings muss jetzt auf Windows Server 2016 mit Excel 2016 migriert werden.

 

Bei der Ausführung auf dem alten System sieht das bei der erfolgreichen Ausführung im Logfile so aus:

 

15.08.2019 12:57:07   Reason  : Info   Creator : EXCEL [EXCEL]   Message : Import.CS:: Scripting Standard Output: 
Microsoft (R) Windows Script Host, Version 5.8
Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten.

Excel started...
Workbook closed...
Excel closed...

 

Auf dem neuen System wird keine csv-Datei generiert. Im Log sieht das dann so aus:

16.08.2019 15:34:32   Reason  : Info   Creator : EXCEL [EXCEL]   Message : Import.CS:: Scripting Standard Output: 
Microsoft (R) Windows Script Host, Version 5.812
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

Excel started...

16.08.2019 15:34:32   Reason  : Info   Creator : EXCEL [EXCEL]   Message : Import.CS:: Scripting Standard Error: 
C:\Program Files (x86)\xyz\xyz\xls_zu_csv.vbs(58, 3) Microsoft Excel: Microsoft Excel kann auf die Datei '\\xyz\xyz\test.xls' nicht zugreifen. Dies kann mehrere Gr�nde haben:

� Der Name des Dokuments oder der Pfad ist nicht vorhanden.
� Das Dokument wird von einem anderen Programm verwendet.
� Der Name der Arbeitsmappe, die gespeichert werden soll, ist identisch zu dem Namen eines anderen Dokuments, welches schreibgesch�tzt ist.

 

Zeile 58 ist die Zeile mit der Funktion app.workbooks.open. Ich bin mir eigentlich ziemlich sicher, dass das neue System auf die Datei zugreifen kann, daher frage ich hier, ob das Problem vielleicht im Script und der Verbindung mit dem neuen System liegen kann. Wie gesagt, das alte System findet mit identischer Konfiguration der Schnittstelle den Pfad, kann die App öffnen usw, und auch die Einstellungen hisichtlich Benutzer, Excel Trust-Center (Pfade im Netzwerk als vertraunswürdig eingestuft z.B.) sind eigentlich identisch.

 

Ich wäre für alle Anregungen sehr dankbar, was hier das Öffnen des Arbeitsblattes unterbinden könnte!

[BOfH_666 577]

vor 27 Minuten schrieb schmimla21:

 

.... Ich habe den Code nicht erstellt und habe auch keine Ahnung :)

 

Allerdings muss jetzt auf Windows Server 2016 mit Excel 2016 migriert werden.

Bei VBS muss ich passen, aber wenn Ihr sowieso schon auf was Frischeres migriert, wie wäre es mit aktueller Technologie? Mit Powershell und dem Modul ImportExcel sollte das ohne Probleme möglich sein und Ihr spart Euch Excel auf einem Server installieren und bezaheln zu müssen. 

bearbeitet 19. August 2019 von BOfH_666

[daabm 1.354]

Du hast vermutlich ein Problem mit Sicherheitszonen... Steck den Hostname und den FQDN des Servers im IE in die Trusted Sites, dann sollte es gehen.

[schmimla21 0]

vor 16 Stunden schrieb daabm:

Du hast vermutlich ein Problem mit Sicherheitszonen... Steck den Hostname und den FQDN des Servers im IE in die Trusted Sites, dann sollte es gehen.

So was hatte ich auch vermutet. Allerdings habe ich dasselbe Problem, wenn ich die .xls auf der lokalen Festplatte speichere und die Datei von dort aus geöffnet werden soll...

 

vor 22 Stunden schrieb BOfH_666:

Bei VBS muss ich passen, aber wenn Ihr sowieso schon auf was Frischeres migriert, wie wäre es mit aktueller Technologie? Mit Powershell und dem Modul ImportExcel sollte das ohne Probleme möglich sein und Ihr spart Euch Excel auf einem Server installieren und bezaheln zu müssen.  

Das man Excel auf dem Server einsparen könnte ist natürlich ein interessanter Punkt, von daher würde ich das in Zukunft in Betracht ziehen. Auf die Schnelle habe ich die Konvertierung aber jetzt mit diesem Modul noch nicht hinbekommen, und ich würde trotzdem gerne erst mal beim "gewohnten" Workflow bleiben.

 

Gibt es vielleicht noch weitere Ideen?

[BOfH_666 577]

Hmmm ... es geht um die Umwandlung einer einfachen Excel-Datei in eine CSV-Datei die den gleichen Namen haben soll?  Na so'n Hexenwerk ist das jetzt aber auch nicht, oder?

$File = Get-Item -Path D:\sample\sample.xlsx
$NewName = Join-Path -Path $File.DirectoryName -ChildPath ($File.BaseName + '.csv')
Import-Excel -Path $File.FullName | Export-Csv -Path $NewName -NoTypeInformation

...  oder fehlt da noch eine wichtige Information?

[NilsK 2.934]

Moin,

 

nur um mich hier mal kurz unqualifiziert einzuklinken: Der oben zitierte Code funktioniert hier mit Windows 10, Excel 2019 (bzw. O365) und einer lokalen Datei anstandslos. Es wird also wohl doch was mit den lokalen Gegebenheiten auf dem Zielsystem zu tun haben.

 

Gruß, Nils

 

[daabm 1.354]

vor 7 Stunden schrieb schmimla21:

So was hatte ich auch vermutet. Allerdings habe ich dasselbe Problem, wenn ich die .xls auf der lokalen Festplatte speichere und die Datei von dort aus geöffnet werden soll...

Kopierst Du die Datei? Dann würdest Du die Sicherheitszone "mitnehmen"... Und was Excel bei Öffnen und dann "Speichern unter" damit macht, da wäre ich dann komplett raus. Ich bin Sysadmin, kein Anwendungsbetreuer

[schmimla21 0]

vor 16 Stunden schrieb BOfH_666:

Hmmm ... es geht um die Umwandlung einer einfachen Excel-Datei in eine CSV-Datei die den gleichen Namen haben soll?  Na so'n Hexenwerk ist das jetzt aber auch nicht, oder?

$File = Get-Item -Path D:\sample\sample.xlsx
$NewName = Join-Path -Path $File.DirectoryName -ChildPath ($File.BaseName + '.csv')
Import-Excel -Path $File.FullName | Export-Csv -Path $NewName -NoTypeInformation

...  oder fehlt da noch eine wichtige Information?

Da fehlen noch einige Einzelheiten, weil sie ursprünglich nicht von Interesse waren: Der Pfad soll zyklisch überwacht werden, ob neue Dateien vorliegen, und diese sollen dann automatisch umgwandelt werden.

 

vor 9 Stunden schrieb daabm:

Kopierst Du die Datei? Dann würdest Du die Sicherheitszone "mitnehmen"... Und was Excel bei Öffnen und dann "Speichern unter" damit macht, da wäre ich dann komplett raus. Ich bin Sysadmin, kein Anwendungsbetreuer  

Auch bei einer frisch lokal angelegten Datei auf dem neuen System tritt das Problem auf.

 

vor 16 Stunden schrieb NilsK:

Moin,

 

nur um mich hier mal kurz unqualifiziert einzuklinken: Der oben zitierte Code funktioniert hier mit Windows 10, Excel 2019 (bzw. O365) und einer lokalen Datei anstandslos. Es wird also wohl doch was mit den lokalen Gegebenheiten auf dem Zielsystem zu tun haben.

 

Gruß, Nils

 

Ja, irgendeine lokale Gegebenheit wird es sein - ich bin nur weiterhin ratlos welche...

[NilsK 2.934]

Moin,

 

füge mal in dem Skript vor der Zeile "set app = ..." folgenden Code ein:

WScript.Echo "Excel-Datei: " & xlsfile
WScript.Echo "CSV-Datei: " & csvfile
WScript.Echo "Datei auffindbar: " & fso.FileExists(xlsfile)

Was gibt das Skript aus, wenn du es ausführst? Werden die Dateinamen korrekt wiedergegeben?

Falls die dritte Antwort "false" ist, dann findet das Skript die Excel-Datei gar nicht erst. Ist sie "true", dann liegt das Problem erst bei Excel.

 

Gruß, Nils

 

[schmimla21 0]

Ergebnis im Log:

21.08.2019 12:04:36   Reason  : Info   Creator : EXCEL [EXCEL]   Message : Import.CS:: Scripting Standard Output: 
Microsoft (R) Windows Script Host, Version 5.812
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

Excel-Datei: \\...\...\...\...\...\...\...\import_excel_test\21_08.xlsx
CSV-Datei: \\...\...\...\...\...\...\...\import_excel_test\21_08.csv
Datei auffindbar: Wahr
Excel gestartet...

21.08.2019 12:04:36   Reason  : Info   Creator : EXCEL [EXCEL]   Message : Import.CS:: Scripting Standard Error: 
C:\Program Files (x86)\...\...\xls_zu_csv.vbs(61, 3) Microsoft Excel: Microsoft Excel kann auf die Datei '\\...\...\...\...\...\...\...\import_excel_test\21_08.xlsx' nicht zugreifen. Dies kann mehrere Grnde haben:

 Der Name des Dokuments oder der Pfad ist nicht vorhanden.
 Das Dokument wird von einem anderen Programm verwendet.
 Der Name der Arbeitsmappe, die gespeichert werden soll, ist identisch zu dem Namen eines anderen Dokuments, welches schreibgeschtzt ist.

Okay, das Problem liegt bei Excel. Wenn ich die Datei im Explorer unter demselben Benutzer auf dem Netzwerkpfad öffne, bekomme ich keine Fehlermeldung. Abspeichern kann ich das testfile auch....

bearbeitet 21. August 2019 von schmimla21

[NilsK 2.934]

Moin,

 

noch zwei Ideen:

• Das Skript wird evtl. durch den Trigger mehrfach gestartet - die erste Instanz öffnet die Datei, die zweite kann sie nicht öffnen.
• Es scheint mir, als würde das Skript von einer Automatisierungslösung gestartet. Ist sichergestellt, dass diese das Skript im richtigen Userkontext ausführt?

Gruß, Nils

 

[BOfH_666 577]

vor 4 Stunden schrieb schmimla21:

Da fehlen noch einige Einzelheiten, weil sie ursprünglich nicht von Interesse waren: Der Pfad soll zyklisch überwacht werden, ob neue Dateien vorliegen, und diese sollen dann automatisch umgwandelt werden.

OK, das "zyklische" wird ja vermutlich bisher auch eher durch eine geplante Aufgabe erledigt, oder? Das könnte man also für ein Powershell-Skript genauso machen. Und die Prüfung auf neue Dateien ist mit Powershell auch nicht kompliziert. Und wenn man das Skript "selbstgebaut" hat, kann man es in Zukunft auch einfacher anpassen, wenn das nötig wird.   ... und selbst wenn nicht, inzwischen bekommt man für Powershell-Skripte schneller/einfacher/mehr Hilfe als für VBS.

[Sunny61 806]

Zum Tipp von Nils mit zweimal geöffnet, sieh im Taskmanager nach ob es mehrere Excel Instanzen gibt. Wenn das Script mit Fehlern beendet wird und es keine Fehlerbehandlungsroutine gibt, werden die vorhandenen Excel Instanzen nicht beendet.

[schmimla21 0]

vor 1 Stunde schrieb NilsK:

Moin,

 

noch zwei Ideen:

• Das Skript wird evtl. durch den Trigger mehrfach gestartet - die erste Instanz öffnet die Datei, die zweite kann sie nicht öffnen.
• Es scheint mir, als würde das Skript von einer Automatisierungslösung gestartet. Ist sichergestellt, dass diese das Skript im richtigen Userkontext ausführt?

Gruß, Nils

 

Korrekt, das Skript wird durch eine Automatisierungslösung alle 60 Sekunden ausgeführt. Das Ganze ist ein relativ komplexes Gebilde: Die Automatisierungslösung startet einen Dienst, der die Datenfiles eben öffnen und analysiert, und die Daten dann in entsprechende Datenbanktabellen schreibt. Die "Automatisierungslösung.exe" schreibtim Grunde eine xml-Datei, in der z.B. der Connect-String der Datenbank (über eine ODBC-Konfiguration) oder das "Abfrageintervall" angegeben wird. Der Dienst wird auf dem alten System wie auch auf dem neuen System mit dem lokalen Systemkonto gestartet.

 

Was mir dabei noch als Unterschied beim alten und neuen System noch auffällt: Auf dem alten Server haben nur die Benutzergruppen "System" und "Administratoren" Vollzugriff auf die Automatisierungslösung. Bei den Berechtigungen auf dem neuen Server sind dagagen noch  die Gruppen(?) "ALLE ANWENDUNGSPAKETE" und "ALLE EINGESCHRÄNKTEN ANWEDNUGSPAKETE" mit lesendem Zugriff aufgelistet. Ist dies vielleicht noch wichtig?

[NilsK 2.934]

Moin,

 

was mir bei der Beschreibung auffällt: Wenn man über die Windows-Aufgabenplanung einen Task baut, der Adminrechte braucht, dann funktionieren diese nur, wenn man das Häkchen setzt "Mit höchsten Rechten ausführen". Fehlt etwas in der Art evtl. bei der hier diskutierten Lösung?

 

Timing-Probleme sind auszuschließen? Etwa in der Art, dass der CSV-Export-Task die Datei zu einem Moment zu öffnen versucht, in dem diese noch vom vorhergehenden Task geöffnet ist?

 

Sonst fällt mir dazu leider nicht mehr viel ein.

 

Gruß, Nils