Inoffizielles deutsches Xbase-Forum

Hallo Hubert

ich versuchs hier nochmals. Du schreibst an anderer Stelle dass du Excel Files mit über 800000 Stätzen erstellst.

Hast du das mal mit LibXl versucht? Ich stehe gerade mächtig an einem Problem an.
Die Exporte nach XLS (XLSX ums genau zu schreiben) werden immer grösser aktuell sind es ca. 186000 Datensätze (10 Werte pro Satz) die in eine Exceltabelle in mehrere Tabs übertragen werden sollen/müssen. Leider stürzt die ganze Anwendung nun immer ohne Fehlermeldung ab. Im Taskmamanger sieht man wie der genutze Speicher von 20MB ansteigt und irgendwo bei 400MB ist die App ohne Kommentar und ohne Meldungs einfach weg. (Abgestürzt, einfach nicht mehr in Action und im Speicher)

Mit einigen 10000 Sätzen weniger geht es, die Speichernutzung steigt aber auch bis über 300MBytes die fertige Exceltabelle ist dann ca. 7MB gross.
[/quote]

Wir erstellen auch Excel-Files via LIBXL.
Ich hab jetzt mal einen Test mit knapp 240.000 Datensätzen (140 bis 200 Byte pro Datensatz) gemacht.
Der Speicher läuft langsam hoch und nach gut 200.000 Datensätzen sind es 640MB dann kam ein IDSC.

Hallo Stefan

Danke für deinen Test! Wir haben z.T auch grössere Datensätze (100-2000+ Bytes pro Datensatz)..... aber dein Test Bestätigt ja eigentlich unser Problem und lässt uns völlig ratlos und demoralisiert vor einem grossen Scherbenhaufen stehen: Den die Exceltabelle mit den Daten (die ständig mehr werden) ist eine zentrale nicht zu ersetzende Aufgabe des Programms ...... Ohne die Tabelle wird alles relativ nutzlos .......

Der Server hat 320 GB RAM ..... ??? Hat jemand evtl. eine Ahnung wie sich die zur Tabellenerstellung auch Nutzen lassen?

hi,

von welcher Xbase++ Version sprecht Ihr

hab Ihr mit der v1.9.255 mal eine "Gegenprobe" gemacht
alternative mit Ot4Xb und "Disphelper" Funktionen für ActiveX

Guten Morgen,

wir verwenden die aktuelleste Xbase++2.0. Testen mit 1.9 kann ich nicht.
Bisher nutzten wir für den Export nur die Excel.Application. Da aber nicht alle Kunden Office habe, setzen wir zusätzlich LIBXL ein.
Ich bin persönlich kein Freund von solch große Datenmengen per Excel, aber wahrscheinlich ist auch bei Carlos der Kunde König.
Per Excel.Application gehen wir den Weg, dass wir eine Textdatei mit TAB und CRLF als Feld- und Satztrenner erstellen
und diese dann per oSheet:queryTables:add("TEXT;" + cFileName, oSheet:cells(2, 1)) ins Excel pumpen.
Eventuell wäre das ein gangbarer Weg?

Gruß
Stefan

Moin,

vielleicht ab und an mal kurze Zwangspausen einbauen um die Runtime zur Ruhe kommen zu lassen?

Und eventuell mal den MemWatcher einbinden um zu schauen, an welcher Stelle der sich zuschaufelt? Xbase++ hatte zumindest früher mal Probleme mit sehr großen Arrays. Das soll angeblich mit der 2.0 inzwischen behoben sein, aber da ich vorsichtshalber weiterhin einen alten Workaroud von Alaska nutze habe ich das nie ausprobiert.

Jan

Danke für die Hinweise.

Das Programm ist ein Dienst auf einem Server der eine Lagerliste erstellt. Da ist Excel mit ActiveX nicht möglich und die Lagerliste auf verschieden Tabelle aufteilen geht schon, funktionert als Notlösung aber kommt bei den Benutzern überhaupt nicht gut an ....

Jan's Tip mit den Array könnte sein ... ich mache da mal Versuche ....

bau mal die funktion sleep(001) z.b. ein. da ist 1 hunderstel pause

Wir haben ein ganz anderes Problem, aber möglicherweise fällt das ins gleiche Problemfeld. Wir hatten sang- und klanglose Abstürze beim Umgang u.a. mit List&Label zu verzeichnen (hier vor allem der PDF-Erzeugung). Ursache war letztlich, wie Xbase++ den Speicher fragmentiert. Es gesteht jeder Anwendung maximal 2 GB Hauptspeicher zu, aber der Anwendung selbst ungefähr zwei Drittel davon, so dass nur rund 600 MB für Komponenten übrig bleiben, und das kann zuweilen zu wenig sein. Die gute Nachricht: Mit Xbase++ 2.0 lässt sich das konfigurieren. Die schlechte: Bei komplexen Anwendungen kann das Einfluss auf die Stabilität der Anwendung selbst haben.

Wir haben mit der Einstellung CDF_MOM_MEMORYSPACE_ID (xpp-cfg.ch) herumgespielt, bis wir einen Wert gefunden haben, mit dem beides gut funktioniert, der liegt jetzt bei 750000 (wir machen das in der ARC-Datei, nicht in der xbpp-cfg.ch, aber die Wirkung ist dieselbe). Probier das doch mal aus, Carlo. Ich vermute sehr, dass Dein letaler Absturz seine Ursache im Speichermanagement hat.

Edit: Wenn die Anwendung sehr klein ist, kann der Wert größer sein, weil die Anwendung dann selbst nicht so viel Speicher braucht.

Tom,

das ist genau die Einstellung, mit der ich die maximalen Arraygrößen steuere. Was aber lt. Alaska mit der 2.0 nicht mehr notwendig sein soll. Meine persönliche Erfahrung war das alles über 970.000 zu ziemlich sofortigem Absturz führte (noch schlimmer als komplett ohne diese Einstellungen). Meist liege ich zwischen 600.000 und 800.000.

Ich bau die auch in die arc ein. Klappt seit hervorragend. Die von Alaska geäußerte Warnung damit vorsichtig zu sein, weil das System sonst performancemäßig massive einbrechen würde, habe ich nie beobachtet.

Jan

Meist liege ich zwischen 600.000 und 800.000.

Irgendwas knapp bei 700 sollte eigentlich der Defaultwert sein (zwei Drittel von 2 GB). Wir haben, wie gesagt, das beste Verhalten bei 750, drüber führt zu AppFreezes. Aber unsere App ist auch ein Trumm sondergleichen.

Was aber lt. Alaska mit der 2.0 nicht mehr notwendig sein soll.

Diese Anmerkung verstehe ich nicht ganz. Die Möglichkeit, die Speicherfragmentierung zu beeinflussen, gibt es doch erst seit der 2.0, oder?

Hallo Tom,

das ist alles schon ewig her. Ich glaube Alaska hatte damals gesagt das der Default bei 2.500.000 liegt. Und die Infos dazu hatte ich im August 2010 bekommen - also vier Jahre bevor die 2.0 raus kam. Damals wurde mir geraten nicht höher als 4.000.000 zu gehen.

Wobei ich mal lernen sollte Nullen zu lesen - in der arc habe ich nicht 600.000 - 800.000 sondern 6.000.000 - 8.500.000 eingetragen.

Nachtrag: Bei mir ging es damals darum das ich Daten importieren wollte. Und die während des Importes auch suchen und anpassen musste. Daher wollte ich das in einem Array machen, halt flexibel und schnell. Da war aber grundsätzlich nach besagten 2.500.000 Sätzen Schicht im Schacht. Deswegen hatte ich Alaska kontaktiert.

Jan

Hallo, Jan.

Das ist ein bisschen eigenartig, denn meines Wissens geht es bei dieser Einstellung darum, wie viel Platz Xbase (in KB) für andere Komponenten übriglässt, was natürlich umgekehrt bedeutet, dass ein sehr kleiner Wert mehr Platz für die Xbase-Applikation selbst einräumen würde. So oder so bin ich ziemlich sicher, dass eine Veränderung (Erhöhung) dieses Werts auch Carlos Problem lösen dürfte.

Wobei ich mal lernen sollte Nullen zu lesen - in der arc habe ich nicht 600.000 - 800.000 sondern 6.000.000 - 8.500.000 eingetragen.

Für welche Konstante? Ich bin sicher, dass es diese Konstante vor zehn Jahren noch nicht gab. Du musst irgendeinen anderen Wert manipuliert haben. Diese Größenordnung lässt mich an die STACK-Einstellung in der XPJ denken.

Tom,

ich sitze gerade bei meinem Kunden. Da habe ich aus genau diesem Grund in der arc diese Zeile stehen:
Und das ist die, um die es bei mir seit August 2010 immer ging im Zusammenhang mit der Anzahl der Array-Elemente. Und Du hast natürlich Recht - hier geht es um HANDLESPACE, nicht um MEMSPACE. Man sollte halt nicht immer nur Anfang und Ende der Konstanten lesen ...

Jan

Jan hat geschrieben: ↑Fr, 14. Apr 2023 17:02 Man sollte halt nicht immer nur Anfang und Ende der Konstanten lesen ...

oder nicht fast schon zwanghaft auf so gut wie jede Post von Tom antworten?

Ihr wisst schon, dass früher bei 64 K Zeilen Schluß war bei Excel ich denke das gilt für alle .XLS Dateien.
Aber auch die modernste Version kommt nicht über 1 Million !!!!

Wenn Ihr also Dateien habt, die schnell und größer geschrieben werden müssen, bleibt aus meiner Sicht nur reines ASCII (also Textdatei),
als CSV könnt Ihr die ja dann mit einem anderen Programm aufteilen.

Ich habe niemals so viele Datensätze in Excel Satz für Satz geschrieben und auch meine HBLIBXL nicht mit solchen Mengen getestet.
Ich öffne meine 800.000 Datensätze DBF mit ActiveX Excel und speichere unter XLSX bzw. XLSB Format.

Ich denke in einer der äußeren Schleifen sollte alle 1000 Durchläufe ein sleep(0) (!!! 0 !!!) stehen,
der gibt den anderen Prozessen kurz Zeit, ohne tatsächlich wirklich stark zu bremsen.

Die Hoffnung ist, dass das System Zeit hat die Speicherverwaltung aufholen zu lassen.

hi,

brandelh hat geschrieben: ↑So, 16. Apr 2023 16:41 Aber auch die modernste Version kommt nicht über 1 Million !!!!

Frage a ChatGPT :
wie viele Zeilen kann EXCEL, in der aktuellen Version, verarbeiten ?

In der aktuellen Version von Excel, Excel 2021 für Windows und Mac, können bis zu 1.048.576 Zeilen verarbeitet werden. Dies gilt für alle Arbeitsmappen im xlsx-Dateiformat, einschließlich neuer Arbeitsmappen, die in Excel 2021 erstellt werden. Bitte beachten Sie jedoch, dass ältere Versionen von Excel möglicherweise eine andere maximale Anzahl von Zeilen unterstützen.

---

ich nutzt für EXCEL inzwischen ADO was bei > 250000 keine Probleme mit einer 32 Bit App macht

wenn Xbase++ 64 Bit "könnte" wäre es wohl kein Problem grosse Datenmengen zu verarbeiten ...

die Begrenzung auf 1 Million Datensätze in Excel ist unabhängig von der BIT Version, ich hab Office 64 bit installiert.
Ich denke es ist einfach der overhead bei ActiveX der irgendwann ein Problem darstellt.

Es könnte ja mal jemand mit C oder delphi versuchen ob LIBXL damit stabiler läuft.

Carlos Anwendung stürzt bei unter 200.000 Excel-Zeilen ab. Carlo, hast Du mal mit der CDF_MOM_MEMORYSPACE_ID gespielt?

In meiner ARC eine Doku zu CDF_MOM_MEMORYSPACE_ID find ich gar nicht ??

eine Doku zu CDF_MOM_MEMORYSPACE_ID find ich gar nicht ??

Das war in der Betaphase, wird aber immer noch unterstützt. XPP_CFG_MOM_MEMORYSPACE = "xpp-integer:<nnnnnn>" ist der offzielle Weg.

Tom hat geschrieben: ↑Mo, 17. Apr 2023 14:07 .... hast Du mal mit der CDF_MOM_MEMORYSPACE_ID gespielt?

Ja, habe ich in der ARC Datei versucht. Bringt jedoch in allen getesteten Varianten eine Fehlermeldung beim Compilieren ....
Was ist der Syntax bezw. was muss genau in der ARC-Datei stehen?

Tom,
meiner Erfahrung nach, sagt der Wert 200.000 Excel-Zeilen alleine nichts aus (richtet sich auch ein wenig nach den Spalten)

Das kann z.B. so in der .arc aussehen.
Ich hatte mal Probleme große XML-Dateien zu öffnen. Damit ging es dann.

Also auch so wie bei Marcus. Seh ich gerade