Office: Excel 2010: Nicht genügend Speicher. Wie debuggen?

Ich möchte Termine in Outlook nach Excel exportieren. Dazu benutze ich Excel als "grafische Bedienoberfläche" mit Eingabefeldern und Start-Button.

Dazu gebe ich in Excel eine Kalenderwoche an, Excel berechnet mir automatisch das Datum von Mo-Fr. Der Start-Button führt ein VBA-Makro aus, das Outlook-Termine ausliest und diese dann nach Datum und Kategorie filtert. Ein paar Termin-Eigenschaften schreibe ich dann in eine neu erzeugte Excel-Datei.

Die meisten KWs funktionieren fehlerfrei. Bei einigen erhalte ich die Fehlermeldung "Nicht genügend Speicher" ohne weitere Details, Fehlercodes o.ä. Ich weiß nicht einmal, wo der Fehler entsteht.

Ich möchte nun gern wissen, wie ich am besten debugge...

Hier der VBA Code:

Wochenbericht - Pastebin.com

Ich habe schon das schrittweise Ausführen getestet. Irgendwann in einer Schleife (bereits nach wenigen [einstelligen] Durchläufen) bricht das Makro dann mit dem Fehler ab.

Ich bin ratlos, da mir Details zum Fehlerbild fehlen. Wie kann ich vernünftig debuggen?

:)

 

Hallo,

setze einen Haltepunkt.

 

Hi,

da musst du halt auch die Schleifen im Einzelschrittmodus durchlaufen und eventuelle Variablen auf ihren Inhalt prüfen. Möglicherweise hast du auch eine Endlosschleife produziert.

 

Hallo droptix,

habe mir das Makro mal näher angesehen, da ich sowas auch öfters mache. Leider hat der Start-Aufruf schon Fehler: Code:

Dabei sind der 3. & 4. Parameter Textwerte, obwohl die Prozedur da Datumswerte erwartet: Code:

Ansonsten sieht es sehr vernünftig aus - aber hier meine Erfahrungswerte dazu:
- gerade bei For-Schleifen im Zusammenspiel von 2 Office-Programmen sollte man mit Hilfe des Befehls 'DoEvents' (siehe Vba-Hilfe) Verschnaufpausen einlegen
- Variablennamen sollten so gewählt werden, das sie keinem Vba-Befehl, einem Vba-Objekt oder einer Objekt-Eigenschaft gleichen
- z.B. Sub Run() - denn es gibt auch Application.Run
- Dim Row As Integer - Cells(3, 4).Row
- Dim Items As Outlook.Items usw.
Statt dessen schreibe ich das so:
Dim Row_ As Integer
Dim Items_ As Outlook.Items
o d e r
Dim xRow As Integer
Dim xItems As Outlook.Items
- benenne die Objekt-Eigenschaft, auch wenn sie in Vba als Standard definiert ist
nicht: ExcelWorksheet.Cells(Row, 1)
sondern: ExcelWorksheet.Cells(Row, 1).Value

Ansonsten schaue ich mir das noch mal näher an.

Gruß von Luschi
aus klein-Paris

 

Die Text-zu-Datum-Wandlung scheint Excel selbst zu machen und das klappt anscheinend auch. Das VBA läuft ein paar Schleifen ja auch problemlos durch. Die Excel-Datei wird erzeugt und die ersten Termine werden fehlerfrei in Excel geschrieben.

In einigen KWs ist der 3. und in anderen erst der 5. Durchlauf der Abbruchkandidat. WAS aber genau zum Fehler/Abbruch führt, sagt mir Excel ja nicht.

Wenn ich Haltepunkte setze oder VBA ein Einzelschritten ausführe, dann zeigt mir Excel im Fehlerfall ja lediglich eine gelb markierte Zeile und einen Pfeil daneben an... keine konkrete Fehlermeldung... kein Hinweis auf die Ursache... gar nichts.

Jedes JavaScript hat ein besseres Debugging :-(

Daher meine Frage, wie ich so debuggen kann, dass ich auch die Ursache ableiten kann? Das WIE ist mir unklar.

 

Weiter geht's im "Trial-and-Error-Debugging" :-)

1. Ich habe *alle* Variablen mit dem Präfix "My" versehen, um Kollisionen mit System- und VBA-eigenen Namen zu vermeiden. Aktualisierter Code hier:

MyWochenbericht - Pastebin.com

Der funktioniert auch weiterhin mit denselben KWs die vorher auch schon fehlerfrei gingen und macht dieselben Fehler in den KWs, die auch vorher schon Fehler produzierten. Soweit "gut".

2. Durch VBA-Ausführen in Einzelschritten gelange ich z.B. für KW51 an folgender Stelle zum Abbruch im 3. Durchlauf der Schleife:

For Each MyAppointmentItem In MyItems
MyRow = MyRow + 1
MyCompanies = ""
For Each MyLink In MyAppointmentItem.Links
Set MyLinkItem = MyLink.Item

Bei `Set MyLinkItem = MyLink.Item` sagt `MyLink.Item`: "Fehler beim Ausführen der Operation."

 

Ich erkenne gerade einen Stolperstein. Es geht darum, dass man Termine mit Kontakten verknüpfen kann (daher die Abfrage nach den `MyAppointmentItem.Links`).

Sort sollte eigentlich eine Outlook-Verknüpfung zu einem Kontakt existieren (oder keine, oder mehrere, ...). ABER in meinem Fall hat dort jemand von Hand eine E-Mail-Adresse eingetragen -> ein Textstring anstelle einer Verknüpfung.

Wenn ich diesen String aus dem Termin entferne, läuft mein VBA Code problemlos durch :-)

Ich scheine das abfangen zu müssen... notfalls lasse ich das ganz raus

 

Hallo,

da ich den Code nicht sehe (und mir von Downloadseiten nichts herunterlade) die Frage: Wie sieht denn Deine Fehlerbehandlung aus?

Grüße
EarlFred

 

Ich habe das so gelöst und es scheint zu funktionieren:

Code:

Trotzdem bin ich etwas sauer, weil das Debugging an und für sich keine wertvollen Rückschlüsse auf die Fehlerursache gibt.

 

Hallo,

Wenn Du mit VBA nicht klarkommst, nimm eine andere Programmiersprache. Office lässt sich nicht nur über VBA steuern

Wenn der Code mit einem Speicherüberlauf krachen geht, kennst Du doch die Fehlerursache: Der Speicher ist voll. Welchen Hinweis erwartest Du? "Sie haben eine Endlosschleife programmiert an dieser Stelle:"?

Zeig doch Deinen Code her, wie er ist, wenn er den Fehler produziert. Und da Du doch schon mittels weniger Einzelschritte an den Fehler herankommst, kannst Du doch auch die Bedingungen, die unmittelbar vor dem Fehler herrschen, darstellen.

Das ist nur ein Ausschnitt und die Fehlerbehandlung ist unvollständig, damit quasi nutzlos.

Row heißt doch immer noch Row - ich dachte, Du wolltest die Namen ändern. Ist der Typ noch Integer? Reicht der Wertbereich von Integer? Bei Blattzeilen nehme ich grundsätzlich Long.

Grüße
EarlFred

 

Oben habe ich meinen kompletten VBA Code verlinkt (pastebin.com) und für meinen Workaround eben nur den relevanten Ausschnitt nochmal geschickt.

Den Code biete ich euch quasi "Open Source" *tongue.gif* www.pastebin.com ist keine Downloadseite, sondern eine Austauschplattform für (langen) Code und Code-Snippets mit Syntax-Highlighting für genau solche Zwecke wie in diesem Forum.

Bin kein VBA-Profi, finde ich aber im Zusammenspiel mit MS Office absolut sinnvoll und praktisch, daher möchte ich das besser verstehen und effektiver scripten.

Debugging ist für mich nicht, den Code schrittweise durchzugehen und zu schauen wann/wo er krachen geht. Das ist Steinzeit. Stell dir vor, das würde in einer Schleife erst nach 1.000 Durchläufen passieren... da fällt mir die Hand ab, wenn ich den in Einzelschritten durchgehe.

Debugging ist für mich eine sinnvolle Fehlermeldung, die mir sagt an welcher Stelle (Zeile + Befehl) der Fehler auftrat und v.a. wieso. Ein bloßes "Nicht genügend Speicher" bringt mich überhaupt nicht weiter. Konkret in meinem Fall hätte ich einen Fehler in der Art erwartet: "Erwartetes Objekt: verknüpfter Kontakt. Gefundenes Objekt: String. Type mismatch." (Pseudo-Formulierung)

Ich programmiere ansonsten viel mit JavaScript, PHP und Python, da bekomme ich eine sehr detaillierte Fehlermeldung. Die Eingrenzung und Fehlerbehebung geht dort deutlich schneller. Ich denke nicht, dass VBA da rückständiger ist, nur kenne ich vielleicht nicht die nötigen Tools?

Meine Frage umformuliert: gibt es bessere Debugging-Möglichkeiten, die mir mehr Details liefern?

 

Hallo Name?,

freilich bietet VBA i. d. R. genau das. Dazu gehört allerdings, dass dieser Fehler auch von VBA gehandhabt werden kann, wozu Dein Speicherüberlauf offenbar nicht gehört. Daher erübrigt es sich m. E., eine Grundsatzdiskussionen an diesem konkreten Fall festzumachen. Es gibt sicher noch genügend andere Fälle, wo eine Fehlermeldung "interpretationswürdig" ist - aber zeige mir eine Sprache, in der der nicht der Fall ist.

Ja, es wäre auch in diesem Fall wünschenswert, die zuletzt ausgeführte Zeile zu kennen und den Zustand der Variablen / des Speichers. Aber was erwartest Du als Fehlermeldung? Die Zeile war / ist vermutlich nicht "falsch", sondern der Speicher schlichtweg voll. Welche Sprache zeigt Dir denn für diesen Fehler eine andere / bessere Meldung an und was ist ihr Inhalt? Was passiert denn in Java, wenn Du den Speicher mit "endlos" vielen Werten zupackst, bis der Speicher voll ist? Poste doch mal die Meldung, damit man eine Vorstellung davon hat, was Du erwartest. Aber ich vermute, auch dort bleibt Dir nur eins übrig: Code "von Hand" auf mögliche Endlosschleifen, Speicherverschwendung etc. zu untersuchen.

Da sind wir genau wieder dem Punkt:

Stell Dir vor, das ist mir klar *wink.gif* Nach Deiner Schilderung tritt der Fehler aber bereits nach wenigen Durchläufen auf, daher ist das wohl doch ein geeignetes Hilfsmittel, neben Haltepunkten, Prozedurschritten usw. Was Du im VBE-Menü unter "Debuggen" gefunden hast, hast Du ja sicher schon durchprobiert.

Ich weiß nicht, warum Du nicht Deine Erkenntnisse aus Deinen Beobachtungen preisgibst, den Code nicht zeigst und auch die Situation vor dem Absturz nicht darstellst. Geht es Dir denn nun um eine Grundsatzdiskussion zum Debuggen unter VBA oder um die Lösung eines konkreten Problems?

Die Hilfe, die wir hier bieten, ist es etwa nicht? Die Codes sind nicht nur einfach "Open Source", sondern sogar zumeist individuelle Kundenwünsche, kostenlos für den Ratsuchenden erstellt. Als erfahrener Programmierer weißt Du dies sicher leicht in Euro umzurechnen.
Und ob Du den Code zeigst, ist Deine Sache. Aber wer will den schon haben, wenn er dauernd abschmiert? *tongue.gif*

Ein "Workaround", der das eigentliche Problem nicht zeigt, ist hübsch, aber nutzt wenig für die Problemsuche.

Wenn Du hier im Forum Fragen zum Code hast, poste ihn bitte hier, gleiches für Mustermappen. Ich habe keine Lust, mir andere Seiten anzusehen und über Code zu reden, den keiner sieht. Ich kenne auch nicht jede Seite mit ihren Eigenarten und habe auch keine Lust, mich damit auseinanderzusetzen. Dennoch danke für den konkreten Tip, vielleicht schaue ich mir die Seite mal grundsätzlich an.
Um (VBA)Code zu posten gibt's ja nun auch hinreichend viele Tools und in den meisten Foren "Code-Tags". Die Darstellung von Code mag unterschiedlicher Qualität sein, aber diese wäre für mich kein Argument gegen das Posten....

Viel geschrieben und Du bist keinen Schritt weiter. Wenn's mein Problem wäre, würde ich anfangen darüber nachzudenken, ob meine Art, das Problem zu beschrieben, für mich zielführend ist. Anstelle mich zu zieren, würde ich die Sache möglicherweise auf den Punkt bringen: Code posten, Mappe posten, Beschreibung verfassen.
Aber jeder, wie er es für richtig erachtet.

Grüße
EarlFred

 

Hallo,

Dafür gibt es Haltepunkte.

 

Ich möchte keine Grundsatzdiskussion halten, sondern (m)ein Problem lösen. Bitte nicht so empfindlich reagieren und jedes Wort auf die Goldwaage legen, ich bin VBA-Beginner... vielleicht drücke ich mich nur kompliziert aus.

Obwohl pastebin ein angesehener Dienst ist, poste ich hier nochmal den vollständigen Code, s.u. (pastebin finde ich halt einfach praktisch, um seitenweise Code in Foren zu vermeiden).

Die genaue Fehlermeldung habe ich mehrfach geschrieben: es poppt ein Fenster auf mit der Meldung "Nicht genügend Speicher" und einer OK-Schaltfläche. Mehr nicht. Sonst wäre ich nicht auf die Idee gekommen hier zu schreiben *tongue.gif*

Wenn ich das Makro über die Schaltfläche in Excel starte, wird die zuletzt ausgeführte Zeile nicht angezeigt. Es kommt einfach das Fenster mit der o.g. Fehlermeldung und Schluss. Durch Einzelschritte habe ich heraus gefunden, dass hier gestoppt wird:

Zeile 69 (gelb markiert): Set LinkItem = Link.Item

M.E. passiert der Fehler aber bereits eine Zeile vorher. Das Dumme: offenbar liegt hier kein Speichermangel im eigentlichen Sinne vor. Wie vorher bereits geschrieben, bricht VBA ab, weil anstelle eines verknüpften Kontakts (Outlook.AppointmentItem.Links) jemand in seinen Termin von Hand eine E-Mail-Adresse reingetippt hat. Also für mich ist das ein Typfehler: Link-Objekt erwartet, aber String bekommen. Und genau das verwirrt... *frown.gif*

Mit Haltepunkten bin ich nicht klar gekommen, ich schau mir das nochmal intensiv an. Keine Ahnung wie sich ein Haltepunkt in einer Schleife verhält.

Code:

 

Bezüglich Debugging:

Bei einem Code ohne Fehlerbehandlung oder auskommentierter Fehlerbehandlung oder Experteinstellung (VBA-Editor / Extras / Optionen / Registerkarte Allgemein / Unterbrechen bei Fehlern / => Bei jedem Fehler) wird die den Fehler auslösende Zeile gelb unterlegt. Fährt man mit der Maus über Variablen, zeigen sich die aktuell vorhandenen Werte. Damit hat man schon einige deutliche Hinweise.

Einen Speicherüberlauf gibt es dann i.d.R. nur bei limitierten Variablen:
- Integer Wertebereich -32.768 bis 32.767 (wurde schon genannt)
- zu klein dinensionierte Arrays

Zusatz: Für eine globale (und technisch herausragende) Fehlerbehandlung kann man sich den vbWatchdog von Wayne Philipps anschauen. Kostet zwar ein kleines Geld, aber ...