VBA Arbeitsmappe schließen in Excel — SaveChanges, die Aufforderung, die Ihr Makro aufhängt, und Schließen ohne Speichern

TL;DR — wb.Close auf einer Arbeitsmappe mit ungespeicherten Änderungen zeigt den modalen Dialog „Möchten Sie die Änderungen speichern?“ — der ein unbeaufsichtigtes Makro für immer einfriert. Beantworten Sie ihn im Code mit dem SaveChanges-Argument:

Sub CloseWithoutPrompt()
    Dim wb As Workbook
    Set wb = Workbooks.Open("C:\Reports\March.xlsx")
    ' ... lesen, was Sie brauchen ...
    wb.Close SaveChanges:=False    ' die Aufforderung im Code beantworten - kein Dialog, kein Haenger
    Set wb = Nothing               ' die Referenz ist nach Close tot
End Sub

Schließen ist der Punkt, an dem ein Stapel-Makro, das die ganze Nacht perfekt lief, am nächsten Morgen noch immer an einem Dialogfeld hängend vorgefunden wird, nachdem es eine von zweihundert Dateien verarbeitet hat. wb.Close schließt nicht einfach eine Arbeitsmappe — es stellt eine Frage, und wenn Sie sie nicht im Code beantworten, fragt Excel den Benutzer, und der Benutzer ist nicht da. Diese Anleitung ruht auf dieser einen Idee: SaveChanges ist Ihre Antwort, und jeder Schließen-Bug ist eine Variante davon, sie zu vergessen.

Was Sie lernen

Das mentale Modell — Close fragt „Änderungen speichern?“; das SaveChanges-Argument ist Ihre Antwort im Code
Der häufigste Hänger — eine geänderte Arbeitsmappe ohne SaveChanges zu schließen friert ein unbeaufsichtigtes Makro ein
Die Spiegelgefahr — SaveChanges:=False verwirft still, entscheiden Sie also bewusst
Warum die Objektvariable in dem Moment, in dem Sie schließen, tot ist und ihr Auslesen einen Fehler wirft
wb.Close (eine Arbeitsmappe) gegenüber Application.Quit (ganz Excel) und die Falle des unsichtbaren EXCEL.EXE
Warum Schließen-mit-Speichern jede Save-Falle erbt

Das mentale Modell: Close stellt eine Frage — beantworten Sie sie im Code

Wenn eine Arbeitsmappe ungespeicherte Änderungen hat, kann wb.Close sie nicht einfach schließen — Excel weiß nicht, ob Sie diese Änderungen behalten wollen. Also tut es, was es für einen Menschen tut: es wirft den Dialog „Möchten Sie die Änderungen speichern?“ auf und wartet. Das ist in Ordnung, wenn eine Person dort sitzt. In einem Makro sind Sie derjenige, der antworten muss, und Sie antworten mit dem SaveChanges-Argument:

wb.Close SaveChanges:=False    ' schliessen und ungespeicherte Aenderungen VERWERFEN
wb.Close SaveChanges:=True     ' zuerst SPEICHERN, dann schliessen
wb.Close                       ' keine Antwort - Excel fragt den BENUTZER (die Aufforderung)

Geben Sie die Antwort im Code, und der Dialog erscheint nie. Lassen Sie ihn bei einer geänderten Mappe weg, sind Sie zurück bei der Aufforderung.

Der häufigste Hänger: kein SaveChanges bei einer geänderten Arbeitsmappe

Das ist der Fehler hinter „mein geplantes Makro wurde nie fertig“. Das Makro öffnet eine Datei, ändert etwas — schon eine Neuberechnung oder ein Worksheet_Change-Handler markiert die Arbeitsmappe als geändert — und dann:

wb.Close      ' geaenderte Mappe, kein SaveChanges -> Dialog "save changes?" -> haengt fuer immer

Es sitzt niemand an der Tastatur, um auf Ja oder Nein zu klicken, also verharrt das Makro unbegrenzt auf diesem modalen Dialog. Der ganze Stapel bleibt dahinter stecken. Die Lösung ist, stets SaveChanges zu übergeben bei jedem Close, der unbeaufsichtigt laufen könnte:

wb.Close SaveChanges:=False    ' schreibgeschuetzte Verarbeitung: verwerfen, nie nachfragen

Wenn Sie sich eine Zeile von dieser Seite merken, dann wb.Close SaveChanges:=False für alles, was Sie nur lesen.

Die Spiegelgefahr: False verwirft still

SaveChanges:=False ist die Kur gegen den Hänger, und es ist zugleich seine eigene Falle. Es wirft ungespeicherte Änderungen ohne Rückgängig und ohne Bestätigung weg. Hat das Makro tatsächlich Arbeit geleistet, die Sie behalten wollten, löscht SaveChanges:=False sie still. Entscheiden Sie also mit Absicht:

Nur die Datei lesen? wb.Close SaveChanges:=False — nichts zu behalten, nie nachfragen.
Ergebnisse geschrieben, die Sie behalten wollen? wb.Close SaveChanges:=True — oder zuerst wb.Save, dann wb.Close SaveChanges:=False, was klarer ist, weil das Speichern und das Schließen getrennte, sichtbare Schritte sind.

Die Aufforderung existiert, um einen Menschen davor zu bewahren, Arbeit zu verlieren. Wenn Sie sie mit einem Argument unterdrücken, übernehmen Sie diese Verantwortung.

Die Referenz ist nach Close tot

Sobald wb.Close läuft, ist die Arbeitsmappe aus dem Speicher verschwunden und die Variable wb zeigt auf nichts. Sie anzufassen wirft einen Fehler:

wb.Close SaveChanges:=False
MsgBox wb.Name          ' FEHLER - wb verweist auf keine geoeffnete Arbeitsmappe mehr

Also lesen Sie alles, was Sie brauchen, bevor Sie schließen, und setzen Sie die Variable danach auf Nothing, um die Absicht deutlich zu machen:

Dim finalName As String
finalName = wb.Name              ' VOR dem Schliessen erfassen
wb.Close SaveChanges:=False
Set wb = Nothing                 ' die Referenz ist tot; sagen Sie es
MsgBox "Closed " & finalName

Eine Arbeitsmappe schließen vs. Excel beenden — und das unsichtbare EXCEL.EXE

wb.Close schließt eine Arbeitsmappe. Application.Quit schließt Excel selbst. Sie sind nicht austauschbar, und zwei Grenzfälle beißen:

ThisWorkbook.Close schließt die Arbeitsmappe, deren Makro gerade läuft. Jeder Code nach dieser Zeile wird womöglich nicht mehr ausgeführt. Schließen Sie andere Arbeitsmappen aus einem Makro heraus; schließen Sie Ihre eigene zuletzt oder gar nicht.
Das Schließen der letzten Arbeitsmappe kann ein unsichtbares EXCEL.EXE laufen lassen. Hält Ihr Code noch eine Referenz auf ein Application- oder Workbook-Objekt, wenn das letzte Fenster schließt, kann Excel nicht vollständig herunterfahren und verharrt als Geisterprozess im Task-Manager. Geben Sie Ihre Referenzen frei (Set wb = Nothing, Set xlApp = Nothing), damit der Prozess beenden kann. Das ist der klassische Bug hinter „Excel läuft weiter, nachdem mein Makro endet“.

Schließen-mit-Speichern erbt jede Save-Falle

wb.Close SaveChanges:=True führt beim Verlassen ein Save aus — also erbt es jede Falle aus VBA Save Workbook:

Bei einer nie gespeicherten Mappe hat Schließen-mit-Speichern keinen Pfad und greift auf das Dialogfeld Speichern unter zurück (hängt). Geben Sie ihr zuerst mit SaveAs einen Pfad, oder schließen Sie mit SaveChanges:=False, wenn Sie sie nicht behalten müssen.
Bei einer mit dem falschen FileFormat gespeicherten Makro-Arbeitsmappe kann Schließen-mit-Speichern erneut die Warnung auslösen, dass Makros entfernt werden. Zählt der Code, ist die Datei .xlsm.

Im Zweifel teilen Sie die Schritte auf: wb.Save (oder wb.SaveAs path, format) in einer eigenen Zeile, dann wb.Close SaveChanges:=False. Zwei sichtbare Operationen schlagen eine, die beides still erledigt.

Das ehrliche Fazit: das Muster der Stapelschleife

Alles Obige läuft auf eine zuverlässige Gestalt hinaus. In einer Ordnerschleife öffnen und schließen Sie innerhalb der Schleife, sodass Sie nie geöffnete Arbeitsmappen ansammeln, die Dateisperren halten:

Dim name As String
name = Dir("C:\Reports\*.xlsx")
Do While name <> ""
    Dim wb As Workbook
    Set wb = Workbooks.Open("C:\Reports\" & name)
    ' ... die Summen lesen ...
    wb.Close SaveChanges:=False       ' in jeder Iteration im Code beantworten
    Set wb = Nothing
    name = Dir                        ' naechste Datei
Loop

SaveChanges:=False ist der Standard für schreibgeschützte Verarbeitung; SaveChanges:=True, wenn Sie Ergebnisse geschrieben haben. Verlassen Sie sich nie auf die Aufforderung, beantworten Sie sie immer, lesen Sie, bevor Sie schließen, und geben Sie die Referenz frei. Tun Sie das, und der Schließen-Schritt — jener, der unbeaufsichtigte Jobs still ins Stocken bringt — wird zum langweiligen, zuverlässigen Ende jeder Datei, die Sie öffnen.

Wie ExcelMaster hilft

Der Schließen-Schritt ist trügerisch gefährlich: Vergessen Sie SaveChanges, und ein geplantes Makro hängt an einem Dialog; übergeben Sie False, wo Sie True meinten, und fertige Arbeit verschwindet; halten Sie eine verirrte Referenz, und Excel verharrt als Geisterprozess. Das sind die Bugs, die nur um 3 Uhr morgens auftauchen, wenn niemand zusieht.

ExcelMaster schreibt das Schließen so, wie es ein sorgfältiger Automatisierungsingenieur täte. Beschreiben Sie den Job — „verarbeite jede Datei in diesem Ordner und schließe jede ohne zu speichern“ — und es öffnet mit Set wb = Workbooks.Open(...), liest, was es braucht, bevor es schließt, übergibt ein ausdrückliches SaveChanges bei jedem wb.Close, gibt die Referenz mit Set wb = Nothing frei und lässt nie eine Arbeitsmappe geöffnet oder einen Excel-Prozess als Geist zurück. Kein Hänger, kein stiller Datenverlust.

Häufig gestellte Fragen

Wie schließe ich in VBA eine Arbeitsmappe ohne zu speichern?

Übergeben Sie SaveChanges:=False: wb.Close SaveChanges:=False. Das beantwortet die Aufforderung „Änderungen speichern?“ im Code mit „nein“, sodass der Dialog nie erscheint und die Arbeitsmappe unter Verwerfen aller ungespeicherten Änderungen schließt. Es ist das richtige Schließen für schreibgeschützte Verarbeitung, bei der es nichts zu behalten gibt.

Warum hängt mein Makro, wenn es eine Arbeitsmappe schließt?

Weil Sie wb.Close auf einer Arbeitsmappe mit ungespeicherten Änderungen ohne ein SaveChanges-Argument aufgerufen haben. Excel zeigt den modalen Dialog „Möchten Sie die Änderungen speichern?“ und wartet auf einen Klick, der in einem unbeaufsichtigten Lauf nie kommt. Übergeben Sie stets SaveChanges:=False oder SaveChanges:=True bei jedem Schließen, das ohne zusehende Person läuft.

Was ist der Unterschied zwischen wb.Close und Application.Quit?

wb.Close schließt eine einzelne Arbeitsmappe und lässt Excel laufen. Application.Quit schließt Excel vollständig, einschließlich jeder geöffneten Arbeitsmappe. Verwenden Sie Close, um in einer Schleife mit einer Datei fertig zu werden; verwenden Sie Quit nur, wenn Ihr Code eine eigene Excel-Instanz gestartet hat und sie herunterfahren muss.

Warum läuft Excel weiter, nachdem mein VBA-Makro die Arbeitsmappe schließt?

Ihr Code hält noch eine Referenz auf ein Workbook- oder Application-Objekt, sodass Excel nicht vollständig herunterfahren kann und als unsichtbarer EXCEL.EXE-Prozess verharrt. Geben Sie die Referenzen frei — Set wb = Nothing und Set xlApp = Nothing — nach dem Schließen, damit der Prozess sauber beenden kann.

Kann ich in VBA die Eigenschaften einer Arbeitsmappe nach dem Schließen lesen?

Nein. Sobald wb.Close läuft, ist die Arbeitsmappe aus dem Speicher, und die Variable verweist auf nichts mehr; wb.Name oder wb.Sheets wirft einen Fehler. Erfassen Sie alles, was Sie brauchen, in Variablen vor dem Aufruf von Close, und dann Set wb = Nothing.

Getestet in

Getestet in: Excel 365 (Windows 11), VBA 7.1 — zuletzt geprüft am 20.08.2026.