Office: Excel 2007 - VBA - Speichern durch Makro auf Server macht Probleme

Hallo Forum,

bei uns laufen die Rechner mit XP, Excel 2007 und der Server läuft noch mit Windows Server 2003.
Seit ich Makros schreibe hat das Speichern via VBA bzw. das Back-Up-erstellen immer problemslos funktioniert.

Seit einiger Zeit hängt sich Excel (oder der Server) aber öfters mal beim Speichervorgang auf. Erst dauert es sehr lange, dann unterbricht der Code und die Meldung "Beenden/Debuggen" erscheint, und Windows meldet dann auch noch "Datenverlust beim Schreiben ... ".
Das tritt NUR beim Speichern via Makro auf, nicht wenn ich händisch über Excel speicher.
Dies passiert nicht immer, und leider für mich auch nicht nachvollziehbar nur bei starker Auslastung (wenn alle Kollegen und alle Programme die Technik an ihre Grenzen bringen), sondern manchmal leider auch wenn ich fast alleine hier sitze und sonst fast nichts läuft.

Klar das die Hard- & Software mal ein Update bräuchte, aber bis es soweit ist, hoffe ich irgendwie eine Besserung zu erzielen.

Hier mal Beispielhaft eine meiner Codezeilen, bei denen dann ausgestiegen wird:

Code:

Workbooks(wkb2).SaveCopyAs Filename:=BackUpOrdner & "\" & WBName2

Wenn ich dann mittels "Debuggen" das Makro von Hand neu anschubse, dauerts zwar etwas, funktioniert aber normalerweise.


Ich hoffe jemand hat eine Idee was ich probieren könnte, oder woran es liegen könnte.

 

Geht bei dem Server irgendwas in den Ruhezustand? Der Rechner selbst, die Festplatte, irgendwas?

Ich kenne ein ähnliches Problem, wenn man auf einen Fileserver zugreifen will und dort ist was im standby. Das Aufwachen dauert dann lange genug, daß der Netztwerktreiber lieber ein timeout sendet, bevor der noch lange weiter wartet. Versucht man's dann nochmal, geht's natürlich, weil der Anschubser vorher dann reichte.

Andere Idee in ähnlicher Richtung: Wenn ich bei mir zu Hause den Rechner hochfahre, der mit der TV-Karte meinen Fernseher versorgt: Dort wird auch eine elektronische Programmzeitschrift geladen, die die Daten auf einer Festplatte ablegt, die an der Fritz!Box hängt. Auch das Ding steigt mir während des Autostarts aus, wenn ich nicht aufpasse, weil:
a) Der WLAN-Treiber ist noch nicht bereit, weswegen das Laufwerk noch nicht gemappt werden kann und vor allem:
b) Die Festplatte wird von der Fritz!Box in den standby gesetzt und wacht nicht schnell genug wieder auf.

Abhilfe: Die Zeitschrift wird mit 30 Sek. Verzögerung gestartet und davor wird mit 10 Sek. Verzögerung eine DOS-Batch gestartet, die im Prinzip nur aus "DIR Z:\" besteht. Damit ist der WLAN-Treiber bereit und die Platte wird "aufgeweckt".

Daß timeout kommt, wenn die Netzlast zu hoch ist und / oder die Server-Hardware allgemein nicht hinterher kommt, das ist... naja... logisch irgendwie...

Nicht, daß die Festplatte schon Oberflächen-Schäden hat uznd zu lange Korrektur-Zeit benötigt, um Anfragen zu beantworten? Das wäre dann natürlich eine ziemlich fatale Erklärung...

Vielleicht geht's ja irgendwie in die Richtung.

Gruß, Michael

 

Hallo Michael,

erstmal danke für Deine Anregungen.

Nicht das ich wüsste.
Bis Anfang des Jahres hat alles problemlos funktioniert (bis auf gaaaaaanz gelegentliche Ausnahmen).

Wenn der Code hängen bleibt und ich ihn durch "Debuggen" neu anschubse, klappts meistens, aber auch nicht immer.

Da mit diesen Excel-Anwendungen nicht nur lokal gearbeitet wird, habe ich vor alle Zugriffe jeweils Prüfungen gesetzt ob Netzwerkverbindung besteht, das entsprechende Laufwerk online ist, der passende Ordner existiert usw.
Aber zum "Aufwecken" würde dies wohl vermutlich eh nix taugen, oder?
Abgesehen davon glaube ich halt auch nicht, dass jetzt urplötzlich etwas aufgeweckt werden müsste, was früher nie nötig war.

In die Richtung gingen meine Vermutungen, aber damit kenne ich mich halt nicht aus.
Deshalb die Hoffnung jemand wüsste irgend etwas womit man mal testen könnte wieso das passiert, oder was man testweise ändern könnte. (Server ausgenommen, da geh und darf ich nicht drann, also nur von meinem Terminal aus bzw. aus Excel heraus)


Im Endeffekt kamen in den letzten Monaten zusätzliche Programme hinzu, die das Netzwerk teilweise spürbar belasten.
Dies würde für die Überlastungs-Variante sprechen.
Da bliebe dann die Frage, ob man sowas mit Excel abfangen kann, z.Bsp. bei zu hoher Last das Speichern abbrechen bevor es zu einem Time-Out kommt, und dann erneut versuchen, um so eine Code-Unterbrechung zu vermeiden.
Immerhin arbeiten mit meinen Makros auch die Kollegen, die im Zweifelsfall keinerlei Hintergrundwissen haben, und zur Not Excel auch einfach mal mit dem Task-Manager beenden wenn was nicht klappt.


Meine andere Überlegung ist, da die Probleme hauptsächlich (nicht nur) bei den umfangreichsten Excel-Projekten auftreten (die inzwischen auch immer umfangreicher geworden sind), könnte mein Programmierstil eventuell Mitschuld sein.
Möglicherweise häufen sich einfach zuviele Datenmengen im Zwischenspeicher (oder sonstwo) an.
Da wäre dann die Frage, wie reduziere ich diese Belastung am sinnvollsten.
Was kann sich da überhaupt anhäufen und eventuell alles verlangsamen?

 

Das kommt drauf an... ;-) Das ist dann ein Zusammenspiel zwischen Netzwerktreiber, Dateisystem und Cache (auf dem Dateisystem).

Die Verbindungen zum Fileserver sind i.a. (ich kenne jetzt auf Anhieb keine Ausnahme) "persistent". D.h., daß die Verbindung quasi "immer" da ist, zumindest aus Sicht des Anwenders, auch wenn sie eigentlich in der Zwischenzeit auch mal getrennt wird. Gutes Beispiel dafür sind Dial-Up-Verbindungen ins internet, die minutenweise bezahlt werden. Da kann man dem Treiber auch sagen, daß er nach 10 Sek. trennen soll, während man sich die Seite durchliest. Geht der Anwender auf eine andere Seite, wird schwupps im Hintergrund die Verbindung schnell wieder aufgebaut.

Das klappt aber nur dort vernünftig, wo die Verbindung auch schnell und fehlerlos wieder aufgebaut werden kann. Wird im o.a. Beispiel die Verbindung ins internet zu langsam aufgebaut, kann es passieren, daß der Browser bereits einen Timeout-Fehler anzeigt, während das Modem immer noch den Carrier durch die Leitung kreischt. Bei ISDN würde das vielleicht nur noch sehr selten passieren und bei DSL gar nicht mehr.

Naja, das mit dem "jetzt plötzlich" ist immer so eine Sache... Oft wundert man sich auch, wieso "jetzt plötzlich" die Waschmaschine kaputt gegangen ist, obwohl sich doch in den letzten 15 Jahren eigentlich gar nichts weiter geändert hat. ;-)

Da etwas zu testen dürfte schwierig sein, zumindest vom Client aus. Durch die Persistenz würdest Du pauschal nie einen Fehler (in der Geometrie) sehen, es könnte aber trotzdem zu Timeouts kommen. Eigentlich müßte die Netzwerklast auf den Karten am Server gemessen werden. Und wenn der nur eine Netzwerkkarte hat: Noch eine rein und "load balancing" betreiben. Funktioniert auch das nicht: Noch einen Server daneben stellen und Aufgaben / Laufwerke verteilen. --> Die Anzahl der Dateien auf dem Fileserver (nicht die Größe, die Anzahl!) kann auch irgendwann das Dateisystem zu sehr verlangsamen. --> Archivieren und Ausmisten... (Das ist aber meist nur eine temporäre Lösung.) Im schlimmsten Fall kann man auch die Server auf mehrere Subnetze verteilen: 192.168.0.1, 192.168.1.1, 192.168.2.1, ...

Das fiese daran ist, daß Du erst weißt, ob es zu einem Teimeout kommt, wenn Du es ausprobierst. ;-) Und vorher testen heißt nicht, daß es 2 Sekunden später im "heißen" Lauf dann nicht doch noch schief gehen wird.

Peter Ustinov war's wohl seinerzeit in der NDR3-Talkshow: "Erfahrung ist eine feine Sache. Leider macht man sie immer erst kurz nachdem man sie gebraucht hätte." (einer meiner 2, 3 Lieblings-Sprüche...)

Alles, was noch "lokal" auf dem Client passiert, ist letztendlich irrelevant. Entscheidend ist erst der Punkt, an dem die vom Client aufbereiteten Daten über's Netz an den Fileserver geschickt werden. Da kann es passieren, daß eine lokale Version der Mappe in Excel im Speicher satte 80 MB beansprucht, während die gespeicherte Datei gerade mal 5 MB hat.

Oha, da gibt's vieles... Die Anzahl der Benutzer, die Anzahl der Dateien, die Größe der Dateien, Software-Verhalten (dauerhaftes Pingen des Servers), ... Letztendlich kann man natürlich auch Defekte nicht ausschließen: langsam sterbende Netzwerkkarten, einstaubende / oxydierende Steckverbindungen, Kabel-Wackler / - Brüche, Störquellen (Stromkabel brummt mit 50 Hertz in das im gleichen Kanal liegende TP-Kabel), ...

Gruß, Michael

 

Hallo Michael,

wie immer danke für Deine Zeit und Erklärungen.
Mich dünkt, im Endeffekt muss ich damit leben bis mal neue Hardware angeschafft wird.

Aber als "Provisorium":
Besteht eine Möglichkeit mittels VBA die Verbindung zum Server "aufzuwecken" bzw. so zu testen, dass ein nachträgliches Speichern möglich sein sollte (mit zeitverzögerung o.ä.)?

 

Yep, deswegen ja mein Beispiel mit der Fernsehzeitschrift: Schick einen Befehl, der garantiert dafür sorgt, daß Server / Platte / wasauchimmer aufgeweckt werden. Schick dann mit Zeitverzögerung dein eigentlichen Befehl hinterher.

Was der 1. Schritt ist? Hmmm... Das kommt wieder drauf an, wie gut / schlecht der Cache auf dem Filesystem ist. Ein einfaches "dir" kann reichen, kann aber auch aus dem Cache bedient werden. Ich hab bei sowas immer gerne eine sog. "Semaphore"-Datei erzeugt:

Mittels "rem. > z:\semaphore.txt" (beachte den . hinter dem rem!) kannst Du eine 0-Byte-Datei erzeugen. Das bedeutet: Es wird ein Eintrag in der Datei-Tabelle angelegt, aber keine Datei selbst. Das sorgt aber dafür, daß eine Platte aus dem standby zurückkommen muß.

Im 2. Schritt kannst Du eine Schleife laufen lassen, die so lange wiederholt wird, bis die Datei auf z:\ erzeugt wurde. Ist sie da, scheint die Platte auch für andere Schreibbefehle verfügbar zu sein. Aber einen Max-Durchlauf der Schleife (Anzahl / Zeit) würde ich vorsichtshalber auch mit einbauen.

Ach, und: Der Dateiname sollte vielleicht nicht konstant "semaphore.txt" sein, sondern vielleicht eher was wie
format$(now(),"YY-MM-DD_hh-mm-ss") & ".txt"
oder so. Damit umgeht man dann auch etwas kniffligere Cache-Strategien. Und nach erfolgtem 2. Schritt sollte die Datei natürlich auch wieder gelöscht werden...

Gruß, Michael

 

Hallo Michael,

zuerst einmal zu Deiner Antwort:
Nach dieser "Semaphore-Geschichte" habe ich mich ein wenig im Netz umgeschaut.
Ist ja eigentlich für etwas (leicht) anderes gedacht, aber da kann ich mich auch täuschen.
Jedenfalls kann ich mit

in Excel nichts erreichen, denn "rem" verwandelt den nachfolgenden Text in einen Kommentar, Punkt hin oder her.
Obendrein stellt sich mir die Frage, wie ich den erzeugten Datenmüll dann wieder weg bekomme?
Werden Null-Byte-Dateien automatisch aufgeräumt, oder müsste man sie explizit mittels "Kill" löschen?

Übrigens, ich habe den ganz starken Verdacht, dass "Dir" auf unseren Terminals (zumindest teilweise) wohl aus dem Cache bedient wird, wie Du ja bereits vermutet hast.


Dann etwas zu meinem Code:
Beim nochmaligen durchlesen meines Eingangsposts bin ich über die "2en" bei

Code:

Workbooks(wkb2).SaveCopyAs Filename:=BackUpOrdner & "\" & WBName2

gestolpert, und habe mir den Code nochmal ganz in Ruhe angeschaut.

Unsere bisherigen Überlegungen gingen wohl leider von etwas falschen Voraussetzungen aus.
Sry dafür, mein Fehler.
Denn wenn der Code in der o.g. Zeile hängen bleibt, müsste der Server längst wach sein, denn es wurde bereits eine Datei gespeichert.
Das Projekt besteht aus zwei Dateien: 1. Mappe enthält den Code, ein paar Blätter, ein wenig Statistik und vor allem alle Bedienfunktionen. Sie dient mir gewisser maßen als "Frontend".
Die 2. Mappe enthält die wirklichen Daten, sie dient mir als "Datenbank".

Wenn o.g. nun Zeile aufgerufen wird (sie speichert ein BackUp der Datenbank-Mappe), wurde ein paar Zeilen vorher aber bereits schon ein BackUp der "FrontEnd-Mappe" gespeichert.

Was ich mir nun vorstellen könnte ist, dass der Code schneller läuft als der Server speichern kann, wenn er eh schon stark belastet ist.
Im Moment habe ich auf Arbeit zwar kaum mal Zeit für sowas, aber ich werde es mal ausprobieren den Code etwas warten zu lassen, sagen wir 2 Sekunden (oder müsste das mehr sein?).
Und dann mal schauen was passiert.


Hier mal der komplette (betroffene & anonymisierte) Code:

Code:

Private Sub CommandButton14_BackUpSpeichern_Click()

    If Me.CommandButton14_BackUpSpeichern.BackColor = &HC0C0C0 Then    'grau
        Me.CommandButton14_BackUpSpeichern.BackColor = &H80FF80        'grün
        Application.Wait Now + TimeValue("00:00:01")
        Application.ScreenUpdating = False
        Call LagerlisteBackupSpeichern
        'Prüfung ob wb bereits geöffnet ist
        For Each wb In Workbooks
            If wb.Name = "Mappe2.xlsx" Then
                Call ArtikelBackupSpeichern
                Exit For
            End If
        Next wb
        Me.CommandButton14_BackUpSpeichern.BackColor = &HC0C0C0        'grau
        Application.ScreenUpdating = True
    Else
        Me.CommandButton14_BackUpSpeichern.BackColor = &HC0C0C0        'grau
    End If

End Sub

Public Sub LagerlisteBackupSpeichern()

c = 1
WBName1 = "Backup Mappe1" & " - " & Format(Date, "yyyy-mm-dd") & " - " & c & ".xlsm"

    'Ordner erstellen falls nicht existiert
    BackUpOrdner = ThisWorkbook.Path & "\BackUp Lagerliste"
    If Dir(BackUpOrdner, vbDirectory) = "" Then
        MkDir (BackUpOrdner)
    End If

    'BackUp Lagerliste
    Ziel = BackUpOrdner & "\" & WBName1
        'Abfrage ob Ziel schon existiert und Backup speichern
        If Dir(Ziel) = "" Then
            ActiveWorkbook.SaveCopyAs Filename:=BackUpOrdner & "\" & WBName1
        Else
            For c = 2 To 999
                WBName1 = "BackUp Mappe1" & " - " & Format(Date, "yyyy-mm-dd") & " - " & c & ".xlsm"
                Ziel = BackUpOrdner & "\" & WBName1
                If Dir(Ziel) = "" Then
                    ActiveWorkbook.SaveCopyAs Filename:=BackUpOrdner & "\" & WBName1
                    Exit For
                End If
            Next c
        End If

    Application.CutCopyMode = False

End Sub

Public Sub ArtikelBackupSpeichern()

c = 1
WBName2 = "BackUp Mappe2" & " - " & Format(Date, "yyyy-mm-dd") & " - " & c & ".xlsx"

    'Ordner erstellen falls nicht existiert
    BackUpOrdner = ThisWorkbook.Path & "\BackUp Lagerliste"
    If Dir(BackUpOrdner, vbDirectory) = "" Then
        MkDir (BackUpOrdner)
    End If

    'BackUp Artikel
    c = 1
    Ziel = BackUpOrdner & "\" & WBName2
        'Abfrage ob Ziel schon existiert und Backup speichern
        If Dir(Ziel) = "" Then
            Workbooks(wkb2).SaveCopyAs Filename:=BackUpOrdner & "\" & WBName2
        Else
            For c = 2 To 999
                WBName2 = "BackUp Mappe2" & " - " & Format(Date, "yyyy-mm-dd") & " - " & c & ".xlsx"
                Ziel = BackUpOrdner & "\" & WBName2
                If Dir(Ziel) = "" Then
                    Workbooks(wkb2).SaveCopyAs Filename:=BackUpOrdner & "\" & WBName2
                    Exit For
                End If
            Next c
        End If

    Application.CutCopyMode = False

End Sub

 

Yep, die sind eigentlich für das Anzeigen eines Status gedacht. Ein Programm kann eine Semaphore anlegen, um damit allen anderen, die es interessiert, zu signalisieren, daß gerade irgendetwas abläuft. Auch kann man sie benutzen, um bestimmte Aktionen auszulösen: Ein Programm wartet in einer Endlos-Schleife darauf, daß eine Semaphore angelegt wird, rattert dann irgendwas durch und löscht die Semaphore dann wieder. Unter Linux sind die Dinger sehr beliebt.

Ich muß allerdings zugeben, daß die erste Seite der Google-Ergebnisse irgendwie nicht in die Richtung geht. Integer-Variablen und Flaggen-Alphabet hatte ich bislang nicht damit in Verbindung gebracht. Sieh die Dinger vielleicht lieber als eine Art Boolean-Variable auf dem Datenträger als erweitertem Arbeitsspeicher.

Ähm... sorry... Da hätte ich vielleicht noch erwähnen sollen, daß das ganze ein DOS-Befehl ist...


Ein entsprechendes Pendant in VBA könnte was mit
open "semaphore.txt" for output as #1 : close #1
sein, bin mir aber jetzt aus'm Stegreif nicht sicher, ob das schon reicht, um die Datei wirklich anzulegen. Kann sein, daß mindestens eine Schreib-Operation in die Datei notwendig ist, womit sie dann aber wiederum nicht mehr "leer" wäre.

Ich würd' meinem Filesystem gehörig auf die Finger patschen, wenn es selbständig Dateien löschen würde. Also: Selbst aufräumen mit dem Datei-Lösch-Befehl Deiner Wahl.

Gruß, Michael

 

Hallo Michael,

Dein Code

Code:

open "semaphore.txt" for output as #1 : close #1

funktioniert wunderbar (bei mir Zuhause getestet).
Danke dafür, denn "open for output" (ebenso wie "input") kannte ich noch nicht.
Du hast also mal wieder Fragen beantwortet, die ich noch garnicht gestellt hatte.
:O)

Ich habe die Zeile mal in etwas Code verpackt (Rohfassung).
So in der Art könnte ich ihn wohl einbauen:

Code:

Option Explicit

Dim strError As String
Dim strFile As String
Dim strDirFile As String

Dim datTime As Date
Dim datEndTime As Date

Public Sub test()

' erstmal alle eventuell vorhandenen "semaphoren" löschen
    strDirFile = Dir("C:\semaphore*")
    strError = "Löschen fehlgeschlagen"
    Do While strDirFile <> ""
        On Error GoTo ErrHand
        Kill "C:\semaphore*"
        On Error GoTo 0
        strDirFile = Dir()
    Loop
    
' solange versuchen bis wirklich gespeichert wurde, bzw. nach 20 sec. abbrechen
    datEndTime = Now + (20 / 86400)
    strError = "Speichern fehlgeschlagen"
    Do Until strDirFile <> ""
        datTime = Now
        If datTime >= datEndTime Then
            strError = "TimeOut beim Speichern"
            GoTo ErrHand
        End If
        strFile = "C:\semaphore " & Format(Now, "yyyy-mm-dd hh-mm-ss") & ".txt"
        On Error GoTo ErrHand
        Open strFile For Output As #1: Close #1
        strDirFile = Dir("C:\semaphore*")
        On Error GoTo 0
    Loop
    
' Aufräumen
    strDirFile = Dir("C:\semaphore*")
    strError = "Löschen fehlgeschlagen"
    Do While strDirFile <> ""
        On Error GoTo ErrHand
        Kill "C:\semaphore*"
        On Error GoTo 0
        strDirFile = Dir()
    Loop
    
    Exit Sub
    
ErrHand:
    On Error GoTo 0
    MsgBox strError
    
End Sub

Den Abbruch nach 20 sec. habe ich mehrfach getestet. In dieser Zeit wurden auf meinem (uralten) Einzelplatzrechner zuhause jeweils 20-21 "Semaphore"-Dateien erstellt.
Wenn so eine kleine Datei auf einem Einzelplatzrechner schon 1 sec. benötigt, wie lange dauerts dann erst übers Netzwerk und mit mehreren MB, bzw. wie lange geduldet sich eigentlich ein Server bis er "TimeOut" schreit?

Da ich mit dem ErrorHandler zugegebener Maßen bisher kaum Erfahrung habe, frage ich mich allerdings, ob er den TimeOut (oder was auch immer) überhaupt abfangen würde, denn der kommt ja nicht von Excel, sondern vom System, oder?

Interessant finde ich, das der "open for output"-Befehl nicht zu einer Warnmeldung führt wenn eine gleichbenannte Datei bereits existiert, sondern sie einfach überschreibt.
Praktisch finde ich, dass "Kill" in Verbindung mit einem String und "*" alle in Frage kommenden Dateien auf einen Schlag löscht. Einerseits logisch, andererseits hätte ich erwartet das die Schleife Datei für Datei abarbeitet.
In dem Zusammenhang habe ich aber auch nicht viel mit "*" experimentiert.
Also wieder was gelernt.


Die Tage werde ich den Code mal in der Firma implementieren, und dann mal schauen.
Rückmeldung gibts auf jeden Fall, kann aber dauern.



Eine Frage hätte ich aber noch.
Dies scheinst Du etwas missverstanden zu haben:

Ich meinte nicht was generell so alles bremsen kann, sondern nur auf eine bestimmte Exceldatei bezogen.
Was kann durch VBA so alles an Müll angesammelt werden, und wie wird man den sinnvoll wieder los?
Bzw. welche Auswirkungen kann dieser Müll haben, und wie lange bleibt er bestehen? Bis die datei geschlossen wird, bis Excel komplett geschlossen wird, bis der Rechner neu gestartet wird, ...

 

Ah so, ok... Naja, dann geht's wieder in die Richtung, wie ich schon schrieb: Alles, was lokal auf dem Client passiert, ist irrelevant. Also:

a) Das Laden / Öffnen der Mappe vom Server geht in die Netzwerklast
b) Das Arbeiten mit der Mappe lokal auf dem Client nicht
b1) (Datei-Sperrung: Wenn jemand weiteres die gleiche Mappe öffnen will, verursacht das einen leichten Peak)
c) Das Speichern der Mappe auf dem Server dann wieder ja

Und dann noch:
d) Wenn die Mappe auf andere Mappen zugreift, um sich Werte zu holen: Last bei jeder Neuberechnung - abhängig von der Größe der Mappe, aus der die Werte geholt werden

e) temporäre Dateien oder sonstige abgespeicherte Ergebnisse auf dem Client (z.B. Laufwerk C:) machen nix aus.

Aber der absolute Überkiller:
f) Eine für gemeinsame Benutzung freigegebene Mappe: Unkontrollierte, wahllose und häufige Last - Da scheint die Mappe fröhlich mit allen Beteiligten zu kommunizieren, über Wetter, Verkehrslage oder die Krisen im nahen Osten, keine Ahnung.

Das Alphabet hat noch ein paar Buichstaben, aber mehr fällt mir jetzt so auf Anhieb nicht ein. Aber da gibt's sicher noch einiges.

Gruß, Michael

 

Hallo Michael,

Okay, Haken drann.

:D:D:D
Auch Haken drann. Benötigen und benutzen wir generell nicht.

Klar.

Unklar, weil:
Im speziellen Fall wird Mappe1 manuell geöffnet.
Sobald die Makros dann erlaubt werden, öffnet sie automatisch Mappe2 (die ist also immer offen wenn mit Mappe1 gearbeitet wird).
In Mappe2 sind keinerlei Formeln, keinerlei automatische Aktualisierungen, kein "Heute()", kein sonstwas...
Alles, aber auch wirklich alles was in Mappe2 geschieht, geschieht per Makro aus Mappe1 heraus.
Und Mappe1 greift auf keine anderen Dateien zu, auch nicht auf geschlossene.

Wenn ich Punkt b) jetzt richtig verstanden habe, müsste Mappe2 dann ja auch lokal auf dem Client laufen, also nur das Netzwerk belasten wenn sie geöffnet bzw. gespeichert wird, oder?

Das würde dann ja eigentlich generell bedeuten: wenn ich vom Netzlaufwerk eine Exceldatei öffne, werden die regelmäßigen Zwischenspeicherungen die Excel von sich aus macht auf dem Client gespeichert? Oder doch auf dem Netzlaufwerk?