VBS: Excel öffnen, aktualisieren und speichern ohne Nachfrage
Ich möchte gerne mittels vbs eine Excel-Datei öffnen, aktualisieren und ohne Nachfrage speichern. Soweit bin ich, leider funktioniert speichern nicht:
Habe ihr einen Tipp für mich?
Gruß okidoki
Set appXLS = CreateObject("Excel.Application")
Set wbkXLS = appXLS.Workbooks.Open("test.xlsx", , true)
wbkXLS.RefreshAll
wbkXLS.SaveChanges = True
wbkXLS.Close 0
Set wbkXLS = Nothing
appXLS.Quit
Set appXLS = Nothing
Habe ihr einen Tipp für mich?
Gruß okidoki
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 81158150187
Url: https://administrator.de/forum/vbs-excel-oeffnen-aktualisieren-und-speichern-ohne-nachfrage-81158150187.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
14 Kommentare
Neuester Kommentar
Denn, aktualisieren tut er die Datei nicht
Wenn du die Mappe mit dem dritten Open-Parameter "ReadOnly" öffnest was erwartest du 🙃?With CreateObject("Excel.Application")
.DisplayAlerts = False
With .Workbooks.Open("test.xlsx",true ,false)
.RefreshAll
.Close True
End With
.DisplayAlerts = True
.Quit
End With
https://learn.microsoft.com/de-de/office/vba/api/excel.workbooks.open
Gruß pp.
Wenn du schon eacapst dann doch bitte alles was muss!
Sind ja auch immer noch einige Syntaxfehler in deinem Code ...🙃. Und wieso überhaupt alles in ne Batch quetschen geht doch simpel mit ner VBS oder PS.
Naja die ewigen Jagdgründe halt...
>print.vbs (
echo With CreateObject^("Excel.Application"^)
echo .DisplayAlerts = False
echo With .Workbooks.Open^("%weg%Ganztag.xlsx",true ,false^)
echo .RefreshAll
echo .Close True
echo End With
echo .DisplayAlerts = True
echo .Quit
echo End With
)
wscript //NOLOGO print.vbs
del print.vbs
Ich bin raus, Kasperltheater 😂
That's all well-documented
https://learn.microsoft.com/en-us/office/vba/api/excel.xlfileformat
https://learn.microsoft.com/en-us/office/vba/api/excel.xlfileformat
Ich bin absolut ersetzlich denn ich weiß den Link auf diese Werte ganz sicher nicht auswendig, gehe aber anders vor als du. Die 51 wird als Argument an SaveAs übergeben. Heißt, eine Suche nach "Excel Workbook SaveAs method" führt dich geradeaus zu
https://learn.microsoft.com/en-us/office/vba/api/excel.workbook.saveas
und dort ist o.g. Seite der XlFileFormat Enumeration für den FileFormat Parameter verlinkt.
That's it ¯\_(ツ)_/¯
Grüße
Steffen
https://learn.microsoft.com/en-us/office/vba/api/excel.workbook.saveas
und dort ist o.g. Seite der XlFileFormat Enumeration für den FileFormat Parameter verlinkt.
That's it ¯\_(ツ)_/¯
Grüße
Steffen
Moin okidoki.
Was deine 1000 Zeilen Code angehen, so wird sich das vermutlich tatsächlich niemand ansehen. Davon ausgehend, dass sich darin 100 GOTO Anweisungen verbergen, obwohl auch Batch bereits seit 25 Jahren prozedural geschrieben werden kann (ohne dir was unterstellen zu wollen, lasse mich auch gern vom Gegenteil überzeugen), ist so etwas nur von dem zu durchschauen, der den Code geschrieben hat. Alle anderen finden sich darin erst nach Stunden zurecht. Und so viel Zeit investiert niemand.
Grüße
Steffen
meine Bemerkung war nur als Kompliment gedacht
Hatte ich so verstanden, danke! Meine Antwort war als Hilfe zur Selbsthilfe gedacht. Vieles ist gut dokumentiert und statt nach der copy/paste Komplettlösung zu suchen, macht es Sinn sich solche Dokumentationen anzusehen und zu verstehen. Dann wird nicht nur die Lernkurve steiler, sondern du kannst dir besser und schneller selbst helfen.Vielleicht hat jemand einen Tipp?
Alles was unter Windows möglich ist, kannst du mit PowerShell umsetzen, incl. grafischen Oberflächen. Mit der Syntax muss man sich natürlich erst mal beschäftigen, aber jede Sprache ist nur Mittel zum Zweck. Wenn du ein gutes Konzept hast und weißt wie man die einzelnen Aufgaben in Codealgorithmen umsetzt, ist die Sprache zweitrangig. Die ganze Fernbedienungsgeschichte von Excel beruht auf der entsprechenden COM Schnittstelle von Office, und zwar sowohl in VBS als auch in jeder anderen Scriptsprache, wie PS. Heißt, das lässt sich einfach von einer in die andere Sprache übernehmen. Davon abgesehen habe ich bis vor ~15 Jahren auch viel mit Excel gemacht, hab aber die Automationen gleich in Excel VBA umgesetzt. In der Regel gibt es keinen Grund um mehr als eine Sprache zu verwenden, sofern diese Sprache alles abbilden kann was man braucht. Alles andere macht es nur unübersichtlich und langsam, da fremder Code auch in anderen Apps läuft für die neue Prozesse gestartet werden. Von z.T. nötigen Kommunikationen zwischen Prozessen, will ich besser gar nicht erst reden.Was deine 1000 Zeilen Code angehen, so wird sich das vermutlich tatsächlich niemand ansehen. Davon ausgehend, dass sich darin 100 GOTO Anweisungen verbergen, obwohl auch Batch bereits seit 25 Jahren prozedural geschrieben werden kann (ohne dir was unterstellen zu wollen, lasse mich auch gern vom Gegenteil überzeugen), ist so etwas nur von dem zu durchschauen, der den Code geschrieben hat. Alle anderen finden sich darin erst nach Stunden zurecht. Und so viel Zeit investiert niemand.
Grüße
Steffen