Programm mit LIBXL stürzt stumm ab

[ramses]

Code: Alles auswählen

#include "xpp-cfg.ch"
CHARACTER
   XPP_CFG_MOM_MEMORYSPACE = "xpp-integer:1048576"

Danke Stefan. Genau ist es. Damit bekomme ich ca. 400'000 Sätze in die Tabelle ... das dürfte noch für einige Zeit genug sein.

[brandelh]

Hallo,

also es liegt nicht an Xbase++ !

LIBXL liefert eine Fehlermeldung, wenn man die Rückgabewerte der Funktionen auswertet und dann die Fehler anzeigt

anbei findet Ihr mein Testprogramm, das mit der aktuellen 2.00 und der letzten 3er LIBXL diese LOG-Datei ausgibt:

Code: Alles auswählen

Big Data Test mit XbpCrt() / Console / OEM Anwendung !

ot4xb() ? =  001.006.003.070

Erstelle XLSX Datei direkt mit den gegebenen Funktionen (oBook KANN NIL sein !):

Dateiname (ohne Endung):  TestBigData

oBook Objekt wurde erstellt !
Fehler bei Zeile      295323  SheetWriteNum() bad allocation
Fehler bei Zeile      295323  SheetWriteStr() bad allocation
Fehler bei Zeile      295323  SheetWriteStr() bad allocation
Fehler bei Zeile      295323  SheetWriteStr() bad allocation
Fehler bei Zeile      295323  SheetWriteStr() bad allocation
Fehler bei Zeile      295323  SheetWriteStr() bad allocation
Fehler bei Zeile      295324  SheetWriteNum() bad allocation
Fehler bei Zeile      295324  SheetWriteStr() bad allocation
Fehler bei Zeile      295324  SheetWriteStr() bad allocation
Fehler bei Zeile      295324  SheetWriteStr() bad allocation
Fehler bei Zeile      295324  SheetWriteStr() bad allocation
Fehler bei Zeile      295324  SheetWriteStr() bad allocation
Fehler beim Speichern:  bad allocation
Ende in 10 Sekunden, oder durch Tastendruck ...

Da die LIBXL aber bei der Funktion SheetWriteStr() "bad allocation" ausgibt und meine EXE weiterhin munter an die Schnittstelle liefert, denke ich meine Behauptung stimmt.
Nach 10 Fehlern gehe ich nun aus der Schleife des Datenexports und das Ende wird protokolliert.

Ich habe das mal an LIBXL.COM gemeldet und gefragt ob das bei C auch passiert.

Ich vermute, dass der Speicher den LIBXL (die DLL) sich reserviert überläuft.

Möglicherweise macht es einen Unterschied, wenn man die Datei nach 250.000 oder 100.000 Zeilen speichert,
die Zeilennummer sich merkt, die Datei neu öffnet und mit den nächsten Daten weiter macht, das hab ich jetzt nicht probiert.

[brandelh]

So ich habe mein Testprogramm um eine Zwischenspeicherung erweitert, bei jeweils 50.000 Datensätzen, aber nach 250.000 kommt dann bald das Ende.

Big Data Test mit XbpCrt() / Console / OEM Anwendung !

ot4xb() ? = 001.006.003.070

Erstelle XLSX Datei direkt mit den gegebenen Funktionen (oBook KANN NIL sein !):

Dateiname (ohne Endung): TestBigData.XLSX

oBook Objekt wurde erstellt !
Zwischenspeichern
OK
oBook Objekt wurde erneut erstellt !
Gibt es die Datei ? J versuche diese zu ”ffnen
Datei geladen, weiter mit oSheet ”ffnen
Ende Zwischenspeichern, weiter mit Export
Zwischenspeichern
OK
oBook Objekt wurde erneut erstellt !
Gibt es die Datei ? J versuche diese zu ”ffnen
Datei geladen, weiter mit oSheet ”ffnen
Ende Zwischenspeichern, weiter mit Export
Zwischenspeichern
OK
oBook Objekt wurde erneut erstellt !
Gibt es die Datei ? J versuche diese zu ”ffnen
Datei geladen, weiter mit oSheet ”ffnen
Ende Zwischenspeichern, weiter mit Export
Zwischenspeichern
OK
oBook Objekt wurde erneut erstellt !
Gibt es die Datei ? J versuche diese zu ”ffnen
Datei geladen, weiter mit oSheet ”ffnen
Ende Zwischenspeichern, weiter mit Export
Zwischenspeichern
OK
oBook Objekt wurde erneut erstellt !
Gibt es die Datei ? J versuche diese zu ”ffnen
Error ! Zip Memory Allocation Failure

Es scheint als ob LibXL nicht geschaffen ist, so große Dateien zu bewältigen.

[AUGE_OHR]

hi Hubert,

ich habe mir mal deinen Source angesehen und kein "sleep" gefunden

Frage : von welcher Xbase++ Version sprichst du ?
wenn v2.x ; hast du das selbe mal mit v1.9 probiert ?

[brandelh]

Sleep() zumindest in der zweiten PRG, wird aber nur benötigt, damit er vor dem Öffnen Zeit hat, die Datei zu finden.

Die Xbase++ Version ist unerheblich, Xbase++ selbst hat ja kein Problem, die Fehlermeldung kommt aus der DLL zurück.
Im 2. Beispiel sieht man, dass das Öffnen zwar noch geht, kurz nach dem Schreiben der weiteren Daten kommt dann wieder der Fehler.
Wichtig, kein Xbase++ Runtime Fehler oder Absturz, sondern die Funktion oSheet:SheetWriteStr() meldet mit .f. einen Fehler,
die Fehlermeldung selbst liefert dann die Funktion der DLL: oBook:BookErrorMessage()

Offensichtlich hat beim LIBXL niemand mit diesen Datenmengen gerechnet.

Ich habe mal den Support angeschrieben, mal sehen was die schreiben.

[AUGE_OHR]

Hi Hubert,

Ich habe mal den Support angeschrieben, mal sehen was die schreiben.

vermutlich wird der Support sagen das es nicht an LibXL liegt ...

[brandelh]

nun ja dann kann man es mit PowerBasic oder C gegentesten ...

[jobbisoft]

Hello guys,

Recently I spoke with libxl support, regarding the reading of an xlsx sheet with more than 88 thousand records and they recommended that either reduce the number of records or switch to 64bits.

HTH
Osvaldo Ramirez

[brandelh]

Diese Antwort habe ich nun auch bekommen, in etwa "die Daten werden alle im Speicher gehalten (der XLSX Datei) und vermutlich läuft der Speicherraum über",
Empfehlung von LIBXL, auf 64 bit wechseln, das geht aber bei mit Xbase++ nicht.

250.000 Zeilen sind aber auch schon wirklich große Dateien, die meisten dürfte das Problem nicht treffen.

Aus meiner Sicht müsste es aber möglich sein, in Xbase++ mit den bekannten Methoden z.B. 10.000 oder 50.000 Datensätze jeweils in einem Array zu buffern,
dann dieses Array an das gewünschte Ziel mit Excel ActiveX zu übertragen, den Zähler hochzusetzen und wieder ein neues Array einzulesen, bis alle Arbeiten erledigt sind.

Ich werde dies aber nicht tun, denn der direkte DBF nach XLSX Export über ActiveX geht wunderbar - solange man die Grenzen von Excel nicht sprengt - und ist schneller.

Für alle Dateien, die nicht sicher auf 1 Million Datensätze zu beschränken sind, ist XLSX eh nicht zu gebrauchen und man sollte sich anderes überlegen.

[Klaus Schuster]

Btw. Mit dem auf der Vorseite vorgeschlagenem Wert konnte ich auch unerklärliche Abstürz von List&Label beheben.

[brandelh]

Hallo,

wie gebt ihr das denn ein ?

Code: Alles auswählen

#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "Inkey.ch"
#include "xpp-cfg.ch"
CHARACTER
   XPP_CFG_MOM_MEMORYSPACE = "xpp-integer:1048576"

*************************
#include "ot4xb.ch"
#include "HBLibXl.CH"
*************************
procedure main()
   local oBook, oSheet, cFile, nActiveSheet

So erhalte ich eine Fehlermeldung:

xpp /q /w /wi /wl /wu /b /dDEBUG /oD:\HB_XBASE\HBLibXL\ZielClassXB @C:\Users\BRANDELH\AppData\Local\Temp\pbdDFD.tmp
Xbase++ (R) Compiler 2.00.1778 Mar 29 2023
Copyright (c) Alaska Software. All rights reserved.
File D:\HB_XBASE\HBLibXL\ZielClassXB\HBLIBXL.PRG successfully compiled.
D:\HB_XBASE\HBLibXL\ZielClassXB\Test-BigData.PRG(8:0): error XBT0250: Incomplete expression
1 error(s) found in file D:\HB_XBASE\HBLibXL\ZielClassXB\Test-BigData.PRG!

auch wenn ich die Zeile mit dem Charakter in die Main stelle gibt es eine Fehlermeldung.

[ssemleit]

Hallo Hubert,

schreib die Zeilen in Deine .ARC Datei. Nicht in die .PRG.

Code: Alles auswählen

#include "xpp-cfg.ch"
CHARACTER
   XPP_CFG_MOM_MEMORYSPACE = "xpp-integer:1048576"

[brandelh]

Danke für den Hinweis

[Klaus Schuster]

Sorry Tom, ich hatte vergessen, dass Du das Thema List&Label bereits angesprochen hattest.
Weiß jemand, ob die Erhöhung des Werts negative Auswirkungen auf das restliche System haben kann?

[Marcus Herz]

Code: Alles auswählen

CHARACTER
   XPP_CFG_MOM_MEMORYSPACE = "xpp-integer:1048576"

Das ist meine Einstellung bei einem Kunden, der immer wieder Problem hatte mit Dll-Calls mit List&Label hatte. Jetzt ist es stabil.
Die App ist nicht zu groß, 8.5 MB, aber es wird den ganzen Tag von bis zu 10 Leuten permanent gearbeitet.
Der Wert entspricht 1 GB also die Hälfte des adressierbaren RAM

[ssemleit]

Guten Morgen,

ich hatte von Alaska den Hinweis,dass die entsprechenden Anpassungen mit Vorsicht vorzunemen sind.
Zu wenig Hauptspeicher destabilisiert den Prozess - was letztendlich der Grund für die Anhebung (1.9 <> 2.0) war.
Mit der 1.9 hatte ich keine Probleme mit großen XML-Dateien.
Mir wurde empfohlen ggf. gesonderte EXEn für die jeweils speziellen Anforderungen zu erstellen.