Excel-Datei kann nicht gespeichert werden.

SlamJam

Neues Mitglied
Thread Starter
Dabei seit
01.09.2006
Beiträge
10
Reaktionspunkte
0
Hallo zusammen

Das Problem ist komplexer als der Titel es beschreiben konnte.

Ich habe ein grösseres VBA-Projekt programmiert, bei welchem User Daten in sehr komplexe Excel-Dateien eingeben. Die User arbeiten teilweise auf PC und teilweise auf Mac. Die Daten werden in einer zentralen Administration gesammelt und automatisch in eine MS-Access DB eingelesen.

Nun kommt es vor, dass einzelne Excel-Dateien von Mac-Useren korrupt bei der zentralen Administration ankommen, oder das einzelne User die Excel-Datei in Mac-Excel nicht mehr öffnen oder nicht mehr speichern können.

Nun habe ich mittlerweile herausgefunden, dass diese Probleme verschwinden, wenn ich die enthaltenen VBA-Module entferne. Nur geht dadurch natürlich auch ein Teil der Funktionalität verloren, ein Teil davon ist relevant für die Datenintegrität.

Ich habe leider im Netz nach längeren Recherchen noch keinen befriedigenden Ansatz gefunden. Die Frage ist, weshalb und unter welchen Umständen der VBA-Code diese Probleme verursacht, wo die Inkompatibilitäten liegen und wie man sie umgehen kann. Derzeit ist mir kein Muster aufgefallen, dass das Phänomen nachvollziehbar macht, es scheint recht spontan aufzutreten. Bei MS-Office von PC tritt dieses Problem nicht auf. Getestet habe ich die Datei derzeit bei Mac OS X und Mac-Office 2004.

Vielleicht hat ja jemand von Euch eine Idee, welchen Weg ich weiter verfolgen könnte.

Besten Dank.

SlamJam
 
Hallo,

ganz einfach: es gibt kein VBA unter Office:mac. Während reine Makros zwischen beiden Systemen ganz gut funktionieren, ist bei VBA-Scripten aus der Win-Welt anders.

Wenn ich mir die Beschreibung Deines Projektes so ansehe bin ich mir nicht ganz sicher, ob nicht ein anderes Verfahren (z.B. Java mit Anbindung an eine Datenbank, z.B. Access oder PHP mit MySQL als Webanwendung) der geeignetere Weg wäre.

Gruß
Peter
 
Hallo Peterg

Aber weshalb funktionieren denn die VBA-Module bei anderen Mac-Office Usern? In der Testphase hatte sich diese Problem nicht gezeigt, die Makros haben funktionert wie sie sollten, ich hatte dies jeweils mit Mac getestet und musste die Makros teilweise auch vereinfachen, damit sie bei allen Systemem liefen.

Zu den anderen Wegen: Natürlich gibt es diese, und über mehr oder weniger geeignet liesse sich natürlich diskutieren. Aber das Projekt ist schon längst in der scharfen Phase, für eine Umkrempelung sind keine Gelder vorhanden. Ich muss das Problem also mit den bestehenden Voraussetzungen lösen.
 
Hallo,

ok - wenn sie grundsätzlich auf einem Mac laufen, nur manchmal nicht, stellt sich die Frage, was bei denen, wo es nicht funktioniert, jeweils anders ist.

Eine häufge Fehlerquelle in meinem Alltag sind unterschiedliche Versionsstände (Releases, Patches), unterschiedliche Konfigurationen und unterschiedliche Installationen (vor allem die sog. Add-Ins). Letzteres kommt immer wieder vor, weil Excel bestimmte Add-Ins (wie Solver oder Analyse-Funktionen) standardmäßig nicht installiert - die muss man per Hand nachinstallieren und aktivieren(!).

Peter
 
Dazu kommt aber noch, dass es ja nicht prinizipell bei diesen Useren nicht läuft, sondern unverhofft auftritt, nachdem es schon eine Weile gelaufen ist.

Anfangen tut es jeweils damit, dass die eingesandten Files bei der zentralen Administration nicht mehr automatisiert eingelesen werden können, da Excel 2003 die Dateien als korrupt meldet.

Der Clou dabei ist, dass, wenn man diese Dateien dann in Open-Office öffnet und neu als Excel abspeichert, diese danach auch wieder in Excel normal geöffnet werden können ..... :rolleyes:
 
Hallo,

wo liegt denn nun der Fehler? Können Anwender die Excel-Dateien teilweise nicht mehr bearbeiten, weil das Makro mit einer kryptischen Fehlermeldung abbricht oder gar nicht mehr startet? Oder können die von Mac-Anwendern gesendeten (per Mail?) Dateien unter Windows nicht geöffnet werden?

Beim Mailversand könnte man z.B. prüfen, ob die MIME-Konvertierung passt. Welches Programm, welche Einstellung? Bei Mail unter Mac OS X gibt tes den zusätzliche Möglichkeit, Dateien Windows-kompatibel zu versenden... Das muss man dann zusätzlich ankreuzen

Peter
 
peterg schrieb:
Hallo,

ganz einfach: es gibt kein VBA unter Office:mac.
Hae?
Es gibt massig Inkompatibilitäten, klar. Aber wenns kein VBA für Office:Mac gäbe, würden die Programme gar nicht laufen. Es geht hier um Excel.

Dass VBA korrupte Dateien produziert ist mir schleierhaft.
Zum Verständnis:
Schreiben die User jeder in eine eigene Datei für sich selbst rein oder ist es eine Datei die mehrfach geöffnet wird?

Wird durch das VBA Script eine Eingabemaske dargestellt die permanent aktiv ist?
Oder ist es ein ereignisgesteuertes Script was automatisch z.B. nach einer Eingabe gewisse Abläufe ausführt?

Dann wäre z.B. denkbar, dass einige User verschiedene Programme geöffnet haben und VBA Excel Werte nicht schreiben kann, weil es nicht den Focus hat, bzw. dass Zellen zwar gefüllt, die Eingabe aber nicht abgeschlossen wird.
Dies würde auch erklären, warum es mal geht und mal nicht.
D.h. probiert doch mal aus, ob da wo die Probleme auftreten diese auch sind, wenn NUR Excel und sonst kein Programm auf ist.

Ich habe auch Probleme, wenn Excel mit einer Eingabemaske "scharf" ist und die Nutzer zwischen den Programmen hin- und herswitchen. Da kann schon mal ein Tastaturbefehl im falschen Programm landen.
 
Aaaaalso:

- Es gibt keine Eingabemaske.

- Jede Person hat eine eigene, personalisierte Datei.

- Es gibt drei Funktionen in einem VBA-Modul.

- Eine von diesen dreien wird durch das Ereignis "Worksheet_Calculate()" auf zwölf Arbeitsblättern der Excel-Mappe aufgerufen und ändert den Zellenkommentar der aktiven Zelle, bei welcher durch ein Dropdown (durch das Gültigkeitsprüfungsmenü erstellt) Werte geändert werden. Diese Information in der Zelle ist nicht essentiell, da man in einem eigenen Tabellenblatt dieselbe Information auch nachsehen könnte.

- Zwei der Funktionen werden durch Klick auf einen Formular-Button im Arbeitsblatt ausgelöst. Die Excel-Datei hat demnach in diesen Momenten immer den Fokus, weil das Ereignis unmittelbar durch eine Aktion des Users in Excel ausgelöst wird.

- Die eine dieser beiden Funktionen macht nichts anderes als die vorbereitete Fensterfixierung aufzuheben und anzuwenden, da die Zellendropdowns (der Gültigkeitsprüfung) bei Mac-Excel nur aktiv sind, wenn keine Fensterfixierung drin ist (gleich wie bei Office 97 für PC). Diese Funktion ist auch zu Vernachlässigen, weil dieser Vorgang auch leicht manuell durchgeführt werden kann. Sie dient ausschliesslich der Benutzerfreundlichkeit.

- Die andere dieser Funktionen fügt per Klick eine neue Zeile ein, in die der User weitere Daten eingeben kann, falls nicht genügend Zeilen zur Verfügung stehen. Dies ist deshalb wichtig, weil eine manuell eingefügte Zeile nicht alle Bedingungen erfüllen würde, welche für das automatisierte Verarbeiten der Datei nötig sind. Diese Funktion ist essentiell. Sie könnte nur umgangen werden, indem zum Vornherein viel mehr Zeilen zur Verfügung stehen würden, was die Übersichtlichkeit erschwert und nur von wenigen Usern gebraucht würde.

@peterg:
Möglicherweise ist die Korruption nach dem Mailversand tatsächlich nicht dasselbe Problem. Die Dateien werden normalerweise vor dem Versand gezippt. Dagegen spricht aber, dass bei gleichen Gewohnheiten die Dateien eine Zeit lang korrekt ankamen, und erst ab einem gewissen Punkt korrupt, aber ab dann immer. Das Versand-Problem wurde mal vom örtlichen Mac-Supporter angesehen, und auch die Art wie die Files gezippt werden.

D.h. es gibt insgesamt drei Probleme:
- Das häufigste ist, dass die Files korrupt in der PC-Administration ankommen und nicht in Access eingelesen werden können, da Excel abstürzt. Zu diesem Problem habe ich in Access per VBA eine Funktion geschrieben, die bei abstürzenden Excel-Files Excel korrekt abschiesst und diese Dateien in einen speziellen Ordner verschiebt. Danach werden diese Dateien allesamt über einen Klick in Open Office geöffnet und neu als Excel abgespeichert, worauf sie sich problemlos in Access einlesen lassen. Soll das einer verstehen ....

- Das zweite Problem ist, dass sich in einem Fall die Datei auf Mac zwar öffnen lässt, und Daten können eingegeben werden, jedoch kommt beim Speichern die Meldung "Datei nicht gespeichert. Alle gespeicherten Kopien wurden gelöscht". Bei älteren Mac-Office Versionen kommt der Fehler 2 beim Öffnen dieser Dateien und Excel stürzt ab. Mittlerweile habe ich getestet dass bei Mac OS X mit Office 2004 sowie auch bei Mac OS 9.1 mit Office 98 diese Probleme nicht mehr auftreten, nachdem das VBA-Modul entfernt wurde.

Aber es kommen keine Makro-Fehlermeldungen.

Das wäre es so in etwa, etwas detaillierter.

Danke für Eure Anteilnahme :)
 
Hallo,

das sind ja gleich mehrere und vermutlich sehr komplexe Probleme.

Trotz gegenteiliger Meinung in diesem Forum und auch unabhängig von den Bezeichnungen: nach meiner Erfahrung haben VBA Office Win und VBA Office Mac nur wenig miteinander gemeinsam. Das eine ist eine ältere Teilversion des anderen (und soll mit der nächsten Version von Office Mac eingestampft werden). Das ist eine permanente Fehlerquelle. Deshalb habe ich mich mit diesem Thema schon lange nicht mehr ausgiebig beschäftigt - doch Jabba kennt das ja offensicht sehr gut...

Hinsichtlich der von Excel als korrupt erkannten Dateien: da bleibt nur der Weg zu prüfen, was auf den betroffenen Maschinen denn nun tatsächlich so passiert (ist). Wird z.B. als Exportfunktion ein Teil eines Arbeitsblattes als separate Excel-Datei gespeichert? Gibt es Änderungen in der System- oder Programmumgebung? Die Zip-Dateien lassen sich offensichtlich klaglos entzippen - am Übertragungsprotokoll kann es also nicht liegen. Doch auch hier ist wohl Kleinarbeit angesagt: wie sieht die Datei vor dem zippen und dem Mailtransport aus? Die Schritte müssten ggf. einzeln durchgegangen und geprüft werden... Doch einen Workaround hast Du hier ja schon.

Du merkst - die Fehlerquellen sind vielfältig. Vermutlich ist es nicht einfach eine Funktion, die mit anderem Parameter aufgerufen werden muss, sondern mehrere Maßnahmen.

Sorry - weitere Ferndiagnose ist mir leider nicht möglich.

Peter
 
Ist schon gut, peterg. Ich find's ja nur schon toll, dass solche Probleme hier ernst genommen werden.

Zum anderen kann ich bestätigen, dass Mac-Excel-VBA in etwa auf dem Stand von VBA für Excel 97 der PC-Version ist, daher habe ich den Code auch auf diesem Stand programmiert.

Die Mailsache könnte man natürlich insofern überprüfen, dass man etwa eine Datei vor Ort auf USB-Stick speichert und dann direkt von dort bei der PC-Admin öffnet. Wenn sich so die Datei öffnen liesse, dann wäre zumindest dieses Problem definitv beim Mailversand zu suchen.

Nun gut. Die Sache ist die, dass der Betrieb in eineinhalb Jahren sämtliche Abteilung auf PC migriert und sämtliche Abteilungen, welche derzeit in einer ganzen Stadt verteilt sind, in einen einzigen Neubau ziehen. Die jetzige Struktur ist eine gewachsene Sache, die sich aus der Zusammenlegung verschiedener Schulen ergeben hat, welche in sich unabhängige Systeme entwickelt hatten.

Ich selber ziehe jedenfalls die Lehre daraus, dass Projekte mit unterschiedlichen Plattformen mit höchster Vorsicht angegangen werden müssen.

Abgesehen davon wird es ev. mal an der Zeit, mit dem Problem bei Microsoft vorstellig zu werden, da es ja nicht ein Mac-Problem an sich ist, sondern ein Office Problem.
 
Visual Basic
Die eigene Script-Sprache Visual Basic wird in der nächsten Version von Office für Mac nicht fortgeführt. Die Mac BU arbeitet hingegen am verbesserten Support alternativer Skriptmethoden, wie AppleScript und Automator. Auch hier wird der plattformübergreifenden Kompatibilität höchste Priorität beigemessen. Einzige Ausnahme bilden auf Visual Basic basierende Makros, die in Dateien integriert sind. Die Dateien selbst können jedoch problemlos geöffnet und bearbeitet werden, ohne die Makros zu beeinflussen. Ferner arbeitet die Mac BU an einer sicheren Verwendung von XML Makros in der nächsten Version von Excel.


Quelle:
http://www.microsoft.com/germany/mac/news_wdc.mspx

No.
 
SlamJam schrieb:
Ich selber ziehe jedenfalls die Lehre daraus, dass Projekte mit unterschiedlichen Plattformen mit höchster Vorsicht angegangen werden müssen.

Abgesehen davon wird es ev. mal an der Zeit, mit dem Problem bei Microsoft vorstellig zu werden, da es ja nicht ein Mac-Problem an sich ist, sondern ein Office Problem.

Ja - das ist ein Kreuz mit der Kompatibilität. Wobei in mir der Verdacht keimt, dass es von den Herstellern tatsächlich so gewollt ist. Was würde denn passieren, wenn Office für den Mac tatsächlich kompatibel zu Office für Win wäre? Warum hat es so lang gedauert (und ist noch immer nicht wirklich gelöst) bis Entourage sich einwandfrei mit Exchange-Servern verständigen kann? Doch schau Dich um: jedes Handy hat seine eigenen Anschlüsse, die Kabel von Palm Tungsten E und Palm Tungsten E2 passen nicht zueinander und die beiden Hersteller von Naßrasierern bringen regelmäßig Klingensysteme, die jeweils einen neuen Rasierer erfordern. Warum sollte es bei Computern anders sein?

Kleine und mittlere Unternehmen starten den (letztlich erfolglosen oder extrem teuren) Versuch, sich auf eine Plattform/System zu verständigen. Große Organisationen können das gleich gar nicht und setzen auf Standards, die man als solche bezeichnen kann. (Umgangssprachlich ist ein Standard das, was fast alle machen - also ein defacto Standard. Ansonsten versteht man darunter eine veröffentlichte Spezifikation, nach der jeder Hersteller sein Produkt erzeugen kann.)

Es ist Freitag und schon spät - ein schönes Wochenende, frei von Computerproblemen ;-)

Peter
 
:)
MoinMoin!
Ich könnte mich jetzt auch (und ich mach das sehr gern! :p) über die besch*** Kompatibilität der Versionen auslassen, allein schon, dass die es nicht geregelt bekommen, die F-Tasten gleich zu belegen, so ein Schmarrn!

Nachdem ich jetzt gelesen habe, was die Makros machen, nochmal eins/zwei Fragen:
Funktioniert das wirklich, wenn Du einfach nur die Module rauswirfst? Das würde ja bedeuten, dass die Module an sich korrupt wären. Und das kann ich mir einfach nicht vorstellen.

Wie Peter vermute ich, dass es beim Versand an sich zu den Problemen kommt. Du sagst, dass es ab einem ziemlich genauen Stichtag Probleme gibt, es vorher aber funktioniert hat.
Eine Möglichkeit noch, lass das Worksheet Calculate mal weg. Du sagt, das sei nicht nötig. Ev. wird beim Öffnen der Excel Datei auf dem Server durch Access schon das Ereignis ausgelöst und die MacVersion der Tabelle interpretiert was falsch und Access kommt daher ins Straucheln.

Die einzigste sichere, aber absolut inakzeptable Lösung: Du musst die VBA Makros auf dem Mac schreiben, dann wirds keine Probleme geben mit ev. nicht vorhandenen Befehlen. Da aber der Editor eine absolute Zumutung beim Mac Office ist, wird das keine sinnvolle Lösung sein.
Auch wenn es sich jetzt blöd anhört: Parallels drauf und ein vernünftiges Win Office installieren. Das ist selbst in der Emulation noch X-fach schneller als die Mac version. Insbesondere die VBA Ausführugsgeschwindigkeit ist beim Mac einfach erbärmlich, einfachste Sachen werden zur Geduldsprobe.
Selbst "damals" zu VPC Zeiten liefen die Makros in der quälend langsamenen Win Umgebung fast so schnell wie originär auf dem Mac, und dafür aber voll kompatibel.

Was norbi geschrieben hat, stimmt mich ein wenig traurig. Aber irgendwie sah und sieht die VBA Umsetzung auf dem Mac sowieso sehr halbherzig und lieblos aus. Und hier im Macuser Forum merkt man sehr stark, dass die "typischen" Macuser Excel eigentlich nur halb, sprich: ohne VBA nutzen. Da kann man die paar Unterschiede natürlich leicht verschmerzen. (Und Excel für Mac sogar "besser" finden :rolleyes:)

Und wenn ihr in 1,5 Jahren sowieso auf PCs umstelllt...
Für mich ein Hauptgrund, warum ich in der Firma nicht auf Mac umstelle. Ich kauf mir doch keine Macs, um dann Win zu installieren damit mein Excel richtig läuft... nööö.

Auf jeden Fall interessiert mich, wie die Geschichte weitergeht!
Vielleicht gibt es eine ganz banale Lösung...
 
Akzeptable Lösung gefunden, wenn auch manuell

Hallo Leute

Das Ganze hat sich mittlerweile weiter entwickelt, und ich habe nun eine Lösung gefunden, mit der ich leben kann.

  • Ich nehme eine x-beliebige funktionierende Excel-Datei meines Projekts als Grundlage (am besten lege ich mir eine Kopie einer neu aus Access erstellten Datei an).
  • Ich lösche sämtliche Tabellenblätter dieses Files.
  • Ich entferne sämtliche benannten Bereiche aus dem File (mache ich per Script, sonst wär's manuell zu mühsam).
  • Ich kopiere sämtliche Tabellenblätter des defekten Files in das Neue.
  • Ich setze die interne Excel-Verknüpfung, welche auf das alte File verweist auf das neue File.
  • Schütze das ganze wieder
  • Und gebe dem ganzen wieder den ursprünglichen Dateinamen.
Darauf hin funzt es auch bei Mac wieder, und zwar inklusive VBA-Scripts.

Es sieht derzeit so aus, dass die Regel nach der der Fehler entsteht wie folgt aussieht:
  • Einzelne Files kommen korrupt bei der zentralen Admin an und werden daraufhin via Open Office "repariert".
  • Wenn es Änderungen für eine Person gibt, wird aufgrund der letzten eingelesenen Datei durch Kopieren derselben eine neue Datei erstellt bei der die Änderungen eingetragen werden.
  • Dateien, die mit Open Office repariert wurden, erzeugen beim erneuten Bearbeiten in Mac besagten Fehler.
Die ursprüngliche Frage wäre natürlich, weshalb so viele Dateien korrupt von Mac ankommen. Diese ist nach wie vor unbeantwortet.

Da die Anzahl defekter Files für die oben erwähnte Spezialbehandlung sich an einer Hand abzählen lässt, und der Reparaturaufwand pro Datei sich im Minutenbereich befindet, belasse ich es wohl bei dieser Handhabung.

P.S. @ Jabba: Ja, bei parallel installiertem Windows, oder Emulation mit PC-Office drauf gibt's keine Probleme. "Worksheet-Calculate" hab ich übr. als Umweg genommen, weil das Change-Ereignis der Zelle bei Office 97/Mac Office nicht funktioniert (ein Bug, es wird gar nicht ausgelöst). Und ja, es funktionierte bei der vorherigen Lösung schlicht durch das Entfernen der Module. Die Arbeitsblätter-Codes musste ich lediglich entfernen, da das Worksheet-Calculate Ereignis sonst nicht mehr vorhandene VBA-Funktionen aufgerufen hätte. Es scheint also schon, dass durch das Gebastel PC-Mac-PC-OpenOffice-PC-Mac der VBA-Code leidet ...

SlamJam
 
Zuletzt bearbeitet:
Hallo,

bist du dir sicher, dass das Ereignis Worksheet_Calculate Ereignis das richtige ist?

Übrigens, ich denke nicht, dass VBA sich großartig in den Plattformen unterscheidet. Lediglich die Semantik ist eine andere.

Funktioniert dein VBA noch? Schon mal das Netzwerk überprüft?
 
Es ist nützlich auf das Datum zu achten, es könnte nämlich gut sein, das SlamJam mittlerweile in Rente ist… ;) (der Thread ist fast 14 Jahre alt)
 
joa, aber seine Lösung würde mich dennoch interessieren, falls es eine gibt. Vielleicht hilft das dann anderen weiter.
 
joa, aber seine Lösung würde mich dennoch interessieren, falls es eine gibt. Vielleicht hilft das dann anderen weiter.
Die in diesem Thead geschilderte urspüngliche Sachlage (#1) ist für die Gegenwart nur insofern von Bedeutung, als dass der Anwender verstehen muss, dass VB und VB(A) nicht nur programminterne Funktionen (hier etwa solche von Excel) nutzen oder nutzen können – diese sind bei plattformübergreifenden Arbeiten unproblematisch –, sondern auch Windows-spezifische Programmierressourcen anzapfen können, die es für MacOSX/macOS nicht gibt.

ActiveX oder .NET sind unter Windows bekannte Entwicklungsumgebungen, die in VB- oder VB(A)-Skripte eingebunden auf dem Mac nicht lauffähig sind.
Umgekehrt würde eine auf dem Mac über AppleScript oder Automator gesteuerte Arbeitsmappe unter Windows ins Leere laufen.
 
Zurück
Oben Unten