Jump to content

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


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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!

Link zu diesem Kommentar
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 von BOfH_666
Link zu diesem Kommentar
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?

Link zu diesem Kommentar

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?

Link zu diesem Kommentar
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 :-)

Link zu diesem Kommentar
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...

Link zu diesem Kommentar

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

 

Link zu diesem Kommentar

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 von schmimla21
Link zu diesem Kommentar

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

 

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
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?

Link zu diesem Kommentar

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

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...