[gelöst] LiO Calc - stürzt nach längerer Makro-Laufzeit ab

[Kappler]

Hallo,

ich habe mir in LiOffice Calc (Version 3.6.4.3) ein Basic-Programm geschrieben, das unsere Lagerbestände nach verschiedenen Kriterien auswertet.
Hierzu wird auf unsere SQL-Server-Datenbank zugegriffen und etliche auch komplizierter verschachtelte SQL-Aufrufe werden durchgeführt.

Soweit funktioniert das auch alles, allerdings stürzt nach Beenden des Makros (Laufzeit ca. 1 Stunde) Calc reproduzierbar ab, wenn ich versuche, das Dokument mit den ermittelten Daten zu speichern.
Gelegentlich kommt noch eine Fehlermeldung ("Fehler beim Speichern..." oder so ähnlich), und dann schließt sich das Calc-Fenster, meistens schließt es sich direkt beim Speicherversuch.

Anschließend wird mir eine Dokumenten-Wiederherstellung angeboten, die auf den Stand vor dem Makro-Aufruf zurückführt.

Auch ein "Speichern unter..." führt zum selben Erebnis.

Ich habe das Makro testweise so modifiziert, dass jeweils 15 Datensätze bearbeitet werden damit anschließend "zwischengespeichert" werden kann.
Aber auch hier stürzt Calc nach ein paar dieser 15-er Aufrufe ab...

Ist irgendein Problem mit Calc in Zusammenhang mit Datenbank-Aufrufen bekannt, das dieses Abstürzen erklären könnte?
Oder besteht die Möglichkeit, dass ich irgendwie so etwas wie ein Speicherleck eingebaut habe wegen dem dies passiert?

Grüße aus dem (badischen) Schwarzwald,
Andreas

[komma4]

Willkommen im Forum

besteht die Möglichkeit, dass ich irgendwie so etwas wie ein Speicherleck eingebaut habe wegen dem dies passiert?

Die Möglichkeit besteht, allerdings -wenn LO auch nach 15 Datensätzen abschmiert- halte ich das für eher unwahrscheinlich.

Aber: ohne den Code zum Speichern zu sehen (am Besten auch den zum Füllen der CALC-Datei) können wir hier nur raten.
Bitte zeige Deinen Code - am Besten in einem Beispieldokument, welches Du als registrierter Benutzer hier im Forum anhängen kannst.

[Kappler]

Danke für die schnelle Antwort und den Willkommensgruß

Ich habe das Dokument mit dem Makro mal angehängt...
Vielleicht fällt ja irgendeine ungeschickte Programmierung auf.
Laufen wird das enthaltene Makro wohl nicht, da es Zugriff auf unsere Datenbank benötigt.

Gespeichert wird nicht aus dem Makrocode heraus, sondern "manuell" nach Beendigung des Programmdurchlaufs.

[Kappler]

Hier angehängt habe ich noch mal die Fehlermeldung, die beim Versuch zu speichern erscheint. (3 Durchläufe mit jeweils 15 Zeilen aus der Datei hat das Makro bis dahin geschafft).

Nach OK habe ich dann versucht, unter anderem Namen zu speichern (speichern unter...), der Dateidialog öffnet sich und sobald ich eine Taste drücke um den Dateinamen zu ändern, unter dem gespeichert werden soll, stürzt Calc ab. (eine Tastatur-Taste bei Eingabe-Focus im Dateinamen-Feld - ich verwende die Office-Dateidialoge).

[balu]

Hallo Andreas,

Code: Alles auswählen

	Dim Name as String

Ist das Korrekt, dass Du die Anweisung Name als String deklarieren musst? Ich kann mir nicht vorstellen das das was Du da machst erlaubt ist. Denn die Anweisung Name ist doch fest vorgegeben als:

Name-Anweisung [Laufzeit]
Gibt einer bereits vorhandenen Datei oder einem bereits vorhandenen Verzeichnis einen neuen Namen.

Aber in deinem Code ist nix davon zu sehen das Du Name wie erlaubt verwendest, sondern im Gegenteil ehern missbrauchst.

Code: Alles auswählen

			Name = StripString(oArtikelRowSet.Columns.GetByName("name").getString())
			If(oSheet.getCellByPosition(1,Zeile).getType =  com.sun.star.table.CellContentType.EMPTY) Then
				oSheet.getCellByPosition(1,Zeile).setFormula(Name)

Garantieren will ich es wohl nicht, aber ich befürchte das dies Office (OOo/AOO/LO) sehr sauer aufstößt. Deshalb würde ich dir dringend raten das zu ändern. Ich stelle mir das ganze dann so vor.

Code: Alles auswählen

	Dim sName as String

Code: Alles auswählen

			sName = StripString(oArtikelRowSet.Columns.GetByName("name").getString())
			If(oSheet.getCellByPosition(1,Zeile).getType =  com.sun.star.table.CellContentType.EMPTY) Then
				oSheet.getCellByPosition(1,Zeile).setFormula(sName)

Als Faustformel solltest Du dir am besten folgendes merken.
Wenn bei der deklaration von Variablen der Variablenname Blau zu sehen ist, dann sollten die Alarmglocken läuten! Denn das bedeutet, dass die Variable schon fest als Anweisung oder als Funktion vom System vergeben ist. In diesem Falle nicht den Variablennamen so nehmen, sondern entweder einen total anderen überlegen oder ihn leicht abändern.

Noch was.

Code: Alles auswählen

    Dim Dummy$ as String

Weißt Du eigentlich was Du da gemacht hast? Ich will dir das mal übersetzen.
Du hast die Kurzform einer Variablendeklaration mit einer Langform davon kombiniert. Richtig ausgeschrieben steht dann nämlich folgendes dort.

Code: Alles auswählen

    Dim Dummy as String as String

Denn das Dollarzeichen direkt am Variablennamen sagt ja schon das es sich um einen String handelt. Folglich ist auch folgende schreibweise zulässug und erlaubt.

Code: Alles auswählen

    Dim Dummy$

Ich hoffe das hilft dir weiter, und ferner hoffe ich das ich nicht daneben lag.



Gruß
balu

[Kappler]

Hallo Balu,

danke für den Hinweis - das probiere ich gleich mal aus...
Da ist bei mir C zu stark im Hirn verankert - das würde mir hier eine Fehlermeldung an den Kopf schmeißen.
Aber auf die Farben bei der Deklaration werde ich (hoffentlich ) in Zukunft achten - guter Tipp...

Gruß
Andreas

[Kappler]

Leider war das nicht das eigentliche Problem - der Absturz beim Speichern nach dem Programmdurchlauf tritt weiterhin auf...

[Kappler]

Ich habe noch etwas weiter geforscht - es scheint mit dem Ressourcenverbrauch zu tun zu haben:

Im Taskmanager verbraucht der Prozess soffice.bin bei frisch geöffnetem Dokument etwa 63.000 Byte.
Bei jeder Datenzeile, die das Programm bearbeitet, erhöht sich dieser Verbrauch um 4.000 bis 12.000 Byte.

Ich lasse das Programm immer 15 Datenzeilen bearbeiten und speichere danach von Hand.
Sobald der Speicherverbrauch von soffice.bin eine Höhe von etwa 700.000 Byte erreicht hat, lässt sich das Dokument nicht mehr speichern und Calc stürzt ab.

Habe ich in meinem Programmcode irgendetwas stehen, was diesen Speicherverbrauch verursacht?
Oder ist dies eher ein "internes" LibreOffice-Problem?

Nachstehend noch das Bild des Taskmanagers mit dem Speicherverbrauch - die Sprünge "nach unten" sind jeweils beim Neustart mit Dokumentenwiederherstellung entstanden...

.

[Karolus]

Hallo
Ich hab den Eindruck das dein gesamter Code sehr ineffizient ist.
( Ein paar Datenbankabfragen mit einer Laufzeit ~1Stunde - Dieses Forum hat auch eine Datenbank im Hintergrund mit ca. 35000 Datensätzen, eine einfache Suche läuft in unter 2 sec ab )

Die Punkte die mir besonders auffallen
- du hast eine extra Function 'stripString( arg )' die nichts tut als ihrerseits rstrip( arg ) zurückzugeben, die kannst du weglassen und direkt die Laufzeitfunction 'rstrip' verwenden
- andererseits hast du mehrere Codeblöcke die völlig identisch ablaufen mit Ausnahme des sql-Statements, diese wiederholten Blöcke könntest du wunderbar in eine Funktion auslagern.
- Datumwerte als Text im Format 'dd.mm.yyyy' die als solche verglichen werden, was glaubst du ergibt:

Code: Alles auswählen

msgbox ( "25.12.1970" > "24.01.2013") 

?
- Die meiste Laufzeit dürfte dabei draufgehen die Zellen einzeln mit 'handgedrechselten' Inhalten zu füllen.

Karolus

[Kappler]

Hallo Karolus,

danke dass du dir meinen Code mal angeschaut hast...

Die Laufzeitfunktion "rtrim(...)" (rstrip ist Python, glaube ich) habe ich inzwischen auch gefunden und mein StripString (das war noch ein Erbe aus der Excel-Zeit) damit ersetzt. Das bringt durchaus einiges an Geschwindigkeit...

Codeblöcke auslagern in eine Funktion wäre bestimmt möglich, zunächst ist es mir aber so wie es ist übersichtlicher was den Ablauf angeht.
Am prinzipiellen Problem des Absturzes würde das wohl auch nichts ändern.

Und die meiste Zeit wird wohl nicht für das Füllen der Zellen benötigt, sondern für die vielen Summenabfragen mit Fallunterscheidung auf die Datenbank:
Der aufwändigste Programmteil ermittelt für drei Jahre nacheindender für jedes Bauteil in welchen Stücklisten es hinterlegt ist und berechnet dann den Verbrauch dieses Bauteils indem ermittelt wird, wie oft das Produkt in dem das Bauteil verbaut ist im jeweiligen Jahr verkauft wurde (über die Rechnungen bzw. Rechnungpositionen).
Mir fällt im Augenblick keine bessere Lösung hierfür ein als zunächst für jedes Bauteil über die Stücklisten zu iterieren und dann für jedes Vorkommen die Rechnungen zu "durchwühlen" (mit der Summenabfrage).
Ich bin aber auch kein SQL-Profi und leider auch noch blutiger OO-Basic-Anfänger...

Das mit dem Datum muss ich mir noch mal anschauen...
Ich hatte "gehofft" dass OO, wenn eine Variable als Date deklariert ist, zugewiesene Strings ins Date-Format castet und Vergleiche auch automatisch im Date-Format vornimmt...
Das ist wohl etwas blauäugig.

[Karolus]

Hallo

Ich hatte "gehofft" dass OO, wenn eine Variable als Date deklariert ist, zugewiesene Strings ins Date-Format castet und Vergleiche auch automatisch im Date-Format vornimmt...

Deine "Hoffnung" wird tatsächlich (wider meine Erwartung) erfüllt. Durch das vorherige 'dim .. as date' wird richtig verglichen.
Trotzdem würde ich die Datumswerte zumindest als Text im Iso-Format 'yyyy-mm-dd' in die Datenbank schreiben.

Mich würde mal interessieren wieviel Zeit die gleichen sql-Abfragen aus Base heraus benötigen?

Karolus

[Kappler]

Auf das Format, in dem die Daten in der Datenbank abgelegt werden, habe ich leider keinen Einfluss:
Die liegen auf einem SQL-Server, die Date-Felder sind dort vom Typ DateTime. Das ist durch unser PPS-System so vorgegeben...
Das Ganze ist über ODBC an eine LiO-Datenbank gebunden über die ich von Calc aus darauf zugreife.
Wie ich direkt aus Basic heraus eine ODBC-Verbindung erstelle habe ich noch nicht herausgefunden.

Ich habe aber jetzt mal mit CDate(...) alle Datenbank-Werte konvertiert.

Mit dem Absturz bin ich (hoffentlich) auch weitergekommen:
Kurz bevor ich wegfahren musste habe ich noch eine Änderung gestartet:
Ich habe alle RowSets mit .Close() geschlossen, nachden ich mit ihnen fertig war und bevor ich sie mit einer neuen SQL-Abfrage neu ausgeführt habe.
Ein erster Versuch hat gezeigt, dass zwar der Speicher immer noch vollläuft, aber bei dem einen Versuch den ich noch machen konnte ließ es sich zumindest abspeichern.
Morgen mal schauen...

[Kappler]

Zu früh gefreut:
Das Makro läuft durch, der Speicher wird vollgeschaufelt (am Ende benötigt soffice.bin etwa 1GB Speicher ) und beim Versuch zu speichern schmiert Calc kommentarlos ab...

Schade, ich hatte gehofft meine Firma etwas aus den Klauen von Microsoft befreien zu können

[komma4]

Bin unterwegs, deshalb nur einen Tipp aus dem Handgelenk:

Schau mal in der Dokumentation ob es in der Nähe von .close auch eine .dispose Anweisung gibt.
Die erste schließt "nur" die zweite verwirft das Objekt (und gibt damit auch belegten Speicher frei).

Vllt auch ein Problem der von Dir genutzten Version - arbeite schon seit Jahren problemlos mit OOo und MySQL bzw Postgresql über JDBC... und immer noch mit OOo 3 2.1

Teste mal mit einer anderen Version, ggfs vom Stick.

Viel Erfolg!

[Kappler]

Hallo Winfried,

ich habe schon statt LibreOffice die aktuelle Version von OpenOffice (portabel) ausprobiert - selbes Ergebnis...

Dispose ist für das Rowset möglich, aber danach kann ich es nicht mehr mit geändertem SQL-Command "wiederverwenden" (was eigentlich logisch ist, das RowSet-Objekt existiert ja nicht mehr).
Muss ich es vor dem erneueten Verwenden mit Redim neu erzeugen und ihm den DB-Kontext neu zuweisen?
In C++ würde ich es mit delete und new machen - bei Basic stehe ich hier etwas auf dem Schlauch... Erzeugt Dim (oder Redim) ein neues Objekt oder dient es nur der Deklaration?

Grüße,
Andreas