StrTran - Nicht genügend Speicher

[Christof]

Hallo in die Runde,

nach langer Zeit habe ich mal wieder ein Problem mit meinem Xbase-Programm, dass ich bisher nicht lösen konnte. Ich lese CSV-Dateien ein, bereinige diese um ein paar Sonderzeichen und übertrage sie letztlich in eine dbf-Datei. So weit, so gut. Für den Austausch der Sonderzeichen nutze ich die Funktion StrTran(). Jetzt habe ich mal eine Datei mit fürchterlich vielen Datenzeilen und mein System meldet: "Nicht genügend Speicher" Befehl: STRTRAN
Hier mal der Bereich, um den es geht:

Code: Alles auswählen

IF !File(cDateiname)
 MsgBox("Datei "+cDateiname+" nicht im Verzeichnis vorhanden!","Meldung")
 aUebertrag:=NIL  // Fehlerhinweis
 cDateiLOG+=Chr(13)+Chr(10)+"Datei war nicht vorhanden: "+cDateiname
ELSE
   cDateiInhalt:=MemoRead(cDateiname)
   oBar:Update(17)
 * O-Zeichen entfernen
   oSay:SetCaption("Nullzeichen entfernen...")
   c2DateiInhalt:="" // damit die Variable leer ist
   >>> c2DateiInhalt:=StrTran(cDateiInhalt,Chr(0)) <<<
   oBar:Update(35)
 * Trennzeichen Semikolon setzen
   oSay:SetCaption("Trennzeichen setzen...")
   cDateiInhalt:="" // damit die Variable leer ist
   cDateiInhalt:=StrTran(c2DateiInhalt,Chr(9),Chr(59))
   oBar:Update(47)
 * Zeilenendezeichen setzen (zunächst raus, wenn schon vorhanden, dann neu
   oSay:SetCaption("Zeilenende kennzeichnen...")
   c2DateiInhalt:="" // damit die Variable leer ist
   c2DateiInhalt:=StrTran(cDateiInhalt,Chr(13)+Chr(10),Chr(10))
   oBar:Update(68)
 * Zeichensatz auf OEM
   oSay:SetCaption("Zeichensatz konvertieren...")
   cDateiInhalt:="" // damit die Variable leer ist
   cDateiInhalt:=ConvToOEMCP(c2DateiInhalt)
   oBar:Update(82)
 * Doppelte Anführungszeichenin einfache tauschen
   oSay:SetCaption("Anführungszeichen entfernen...")
   c2DateiInhalt:="" // damit die Variable leer ist
   c2DateiInhalt:=StrTran(cDateiInhalt,Chr(34),"'")
   oBar:Update(100)

 cDateiInhalt:=""
 oSay:SetCaption("Einlesen in den Speicher...")
 aUebertrag:=Str2Array(c2DateiInhalt,Chr(10),@oBar)
 c2DateiInhalt:=""
 oBar:Update(100)
 cDateiInhalt:=NIL
 Sleep(10)
 nAnzSaetze:=Len(aUebertrag)

Die Fehlermeldung bezieht sich auf die Zeile mit >>> <<<. Die merkwürdige Vorgehensweise mit c2DateiInhalt und cDateiInhalt habe ich mal ausprobiert, um immer wenigsten eine "leere" Variable zu haben. Hat aber nichts genutzt.

Vielleicht habt Ihr einen Tipp für mich?!

Ach, es läuft auf Windows 10, Rechner mit 16 GB Hauptspeicher und auf der Platte sind noch 160 GB frei.

Vielen Dank und viele Grüße

Christof

[brandelh]

du liest die Datei auf einen Schlag in den Hauptspeicher, der ist bei Win32 Bit auf irgendwas um 2 GB für die Daten begrenzt.
Mit StrTran() musst du dann die Variable mindestens 2x in diesen bekommen, weshalb meist bei 400 MB Schluss ist (auf einem 64 Bit Windows),
um diesem Problem aus dem Wege zu gehen, ist es besser mit meiner Funktion HBTextReader( cFile ) die Datei zeilenweise einzulesen und zu verarbeiten:

viewtopic.php?p=88725#p88725

Der Hauptspeicherbedarf sinkt dramatisch.

[Christof]

Hallo Hubert,

erstmal vielen Dank für die Rückmeldung. ich hatte mich schon gefreut, dass es eine sehr gute Lösung von Dir gibt, aber auch befürchtet, dass es nicht so einfach ist. Ich bekomme folgende Fehlermeldung:

Code: Alles auswählen

FEHLERPROTOKOLL von "E:\KAP\HBTextReader\hbtextreader.exe" Datum: 25.09.2023 09:55:14

Xbase++ Version     : Xbase++ (R) Version 2.00.1741
Betriebssystem      : Windows 10 2009 Build 19045
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: U VALUE: NIL
          -> VALTYPE: C VALUE: ÿþP e r s o n e n n u m m e r 	 e r s t e s   K o n t o e r ö f f n u n g s d a t u m   ( N U M ) 	 A n z a h l   K o n t e n 	 A n z a h l   K o n t e n / V e r t r ä g e   i n k l .   V e r b u n d 	 A v a l s a l d o 	 B a n k k a r t e n a n z a h l 	 B a u s p a r v e r t r a g a n s p a r a n z a h l 	 B a u s p a r v e r t r a g a n s p a r s a l d o 	 B a u s p a r v e r t r a g d a r l e h e n a n z a h l 	 B a u s p a r v e r t r a g d a r l e h e n s a l d o 	 D a r l e h e n s k o n t e n a n z a h l 	 D a r l e h e n s k o n t e n s a l d o 	 D e p o t k o n t e n a n z a h l 	 D e p o t k o n t e n s a l d o 	 D Z I   W ä h r u n g s a n l a g e n a n z a h l 	 D Z I   W ä h r u n g s a n l a g e n s a l d o 	 D Z I   W ä h r u n g s k r e d i t a n z a h l 	 D Z I   W ä h r u n g s k r e d i t s a l d o 	 D Z P   F o n d a n z a h l 	 D Z P   F o n d a n z a h l   2 .   D e p o t i n h a b e r 	 D Z P   F o n d s a l d o 	 D Z P   F o n d s a l d o   2 .   D e p o t i n h a b e r 	 E i g e n k a p i t a l k o n t e n a n z a h l 	 E i g e n k a p i t a l k o n t e n b e t r a g 	 F e s t g e l d e r a n z a h l 	 F e s t g e l d e r s a l d o 	 F i r m e n v e r s i c h e r u n g s a n z a h l 	 F o n d s a n z a h l   1 .   D e p o t i n h a b e r 	 F o n d s s a l d o   1 .   D e p o t i n h a b e r 	 G e n o - B r o k e r   D e p o t k o n t e n a n z a h l 	 G e n o - B r o k e r   D e p o t k o n t e n s a l d o 	 G e s c h ä f t s a n t e i l s k o n t e n a n z a h l 	 G e s c h ä f t s a n t e i l s k o n t e n s a l d o 	 H a b e n s a l d o   K o n t e n 	 H a b e n s a l d o   K o n t e n   i n k l .   V e r b u n d 	 H y p o t h e k e n d a r l e h e n a n z a h l 	 H y p o t h e k e n d a r l e h e n a n z a h l   D Z   H Y P 	 H y p o t h e k e n d a r l e h e n b e t r a g 	 H y p o t h e k e n d a r l e h e n b e t r a g   D Z   H Y P 	 K a p i t a l - L V - R ü c k k a u f s w e r t s a l d o 	 K o n t o k o r r e n t k o n t e n a n z a h l 	 K r e d i t k a r t e n a n z a h l 	 O n l i n e k o n t e n a n z a h l 	 P e r s o n e n v e r s i c h e r u n g s a n z a h l 	 R + V   L u x e m b u r g   V e r s i c h e r u n g s s u m m e 	 R + V   L u x e m b u r g   V e r t r a g s a n z a h l 	 S a c h v e r s i c h e r u n g s a n z a h l 	 S o l l s a l d o   K o n t e n 	 S o l l s a l d o   K o n t e n   i n k l .   V e r b u n d 	 S p a r b r i e f e a n z a h l 	 S p a r b r i e f e s a l d o 	 S p a r k o n t e n a n z a h l 	 S p a r k o n t e n s a l d o 	 S p i e g e l k o n t o a n z a h l 	 T e a m B a n k   K r e d i t a n z a h l 	 T e a m B a n k   K r e d i t s a l d o 	 T e l e b a n k i n g k o n t e n a n z a h l 	 G e s a m t h a b e n s a l d o   D a r l e h e n 	 F r e i s t e l l u n g s b e t r a g   B a n k e i g e n 	 F r e i s t e l l u n g s b e t r a g   V e r b u n d   ( 1 .   K u n d e ) 	 V e r f ü g b a r e r   B e t r a g   B a n k e i g e n 	 V e r f ü g b a r e r   B e t r a g   V e r b u n d   ( 1 .   K u n d e ) 	 D u r c h s c h n i t t s h a b e n s a l d o   K K 	 D u r c h s c h n i t t s s o l l s a l d o   K K 	 G e s a m t h a b e n s a l d o   K K 	 G e s a m t s o l l s a l d o   K K 	 G e h a l t s e i n g a n g   l f d .   M o n a t 	 G e h a l t s e i n g a n g   V o r m o n a t 	 G e s a m t g e h a l t s e i n g a n g   l f d .   J . 	 G e s a m t g e h a l t s e i n g a n g   V o r j a h r 	 K u n d e n b e z i e h u n g s m o n a t e 	 b a n k e i g e n e   G A A - U m s a t z a n z a h l 	 b a n k e i g e n e   G A A - U m s a t z v o l u m e n 	 b a n k f r e m d e   G A A - U m s a t z a n z a h l 	 b a n k f r e m d e   G A A - U m s a t z v o l u m e n 	 B a r u m s a t z a n z a h l 	 B a r u m s a t z v o l u m e n 	 B e l e g u m s a t z a n z a h l 	 B e l e g u m s a t z v o l u m e n 	 D a u e r a u f t r a g s u m s a t z a n z a h l 	 D a u e r a u f t r a g s u m s a t z v o l u m e n 	 D T A - U m s a t z a n z a h l 	 D T A - U m s a t z v o l u m e n 	 G e s a m t h a b e n u m s ä t z e   K K   l f d .   J . 	 G e s a 
oError:canDefault   : N
oError:canRetry     : N
oError:canSubstitute: J
oError:cargo        : NIL
oError:description  : Parameter hat falschen Typ
oError:filename     : 
oError:genCode      :          2
oError:operation    : <NIL>$<ÿþP e r ...>
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :       1025
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von HBTXTREADER:GETLINE(191)
Aufgerufen von MAIN(58)

Das Problem sind wohl die beiden Zeichen am Anfang der Datei. Die Datei kommt aus einem Großrechnersystem und das kann ich auf nicht ändern. Warum auch immer diese blöden beiden Zeichen da sind...

Es handelt sich um die Zeichen FF und FE (also ASCII 255 und 254).

Es ist eine UTF-8-Codierung (?), so dass immer ein zweites Byte mit Wert "0" vorhanden ist. In meinem ersten STRTRAN lösche ich genau diese 0-Werte und bekomme dann schon eine nur noch halb so große Datei. Aber bei einer Dateigröße von ca. 550 MB klappt das halt nicht mehr.

Super wäre, wenn die Klasse darauf reagieren könnte. WENN nämlich jemand die Datei schon bearbeitet oder anderweitig umgewandelt hat, sind diese beiden Zeichen am Anfang und die 0-Werte ggf. nicht mehr da.

Ich probiere natürlich auch mal, ob ich einen Weg finde, aber ich freue mich auch, wenn Du mir einen Tipp gibst.

Viele Grüße
Christof

[Jan]

Hallo Christof,

Du arbeitest ja mit Xbase++ 2.0. Mach doch erst mal mit Utf82Char() eine Konvertierung auf ANSI, dann Dein StrTran(), und notfalls hinterher per Char2Utf8() wieder zurück nach UTF-8 wenn das benötigt wird.

Jan

[Marcus Herz]

Das ist eine UTF-16 Codierung, nicht UTF-8.
FF FE bedeutet little endian, das 1. byte steht links, sprich in deinem Fall kommt das leer Byte rechts.
Das löst aber nicht das Speicherproblem.
Theoretisch könnte ein Zeochen auch 4 Bytes beötigen (Smilies zum Beispiel). Das dürfte aber bei Datenexport nicht vorkommen.

[Marcus Herz]

Wenn du die Daten in eine Variable lesen kannst, dann lauf doch einfach per Schleife drüber, das dollte den wenigsten Speicherplatz benötigen:

Code: Alles auswählen

nLen	:= len(cExport)
cNeu	:= space(nLen / 2)
for i := 1 to nLen /2
	cNeu[i] := cExport[i*2-1]
next

Wenn das wegen Speicher auch nicht geht, musst du auf Hubert's Klasse switchen

[Marcus Herz]

apropos: Bist du dir sicher, dass jedes 2. Byte 0 ist, Umlaute benötigen beide Bytes.

[Christof]

Erstmal "Danke, dass Ihr Euch Gedanken gemacht habt!".

Hmmm... das mit der Variablen muss ich mir mal näher anschauen.
Da mein Fehler ja erst nach der Übernahme mit Memoread kommt, könnte das ein Weg sein.

Ja, die Umwandlung an sich ist ja nicht das Problem. Das mache ich ja schon ein paar Jahe so. Das Problem ist, dass ich jetzt eine SEHR große Datei habe, die den Speicher sprengt. Ein paar Sleep(0) hatte ich auch schonmal eingebaut, um dem Garbage Collector Gelegenheit zu geben, aber hat noch nichts genutzt.

Weitere Vorschläge werden gerne entgegengenommen.

Gruß

Christof

[flanelli]

Hallo Christof,

Weitere Vorschläge werden gerne entgegengenommen.

Als Alternative zu Huberts Klasse könnte man auch diesen Weg wählen.
Verwenden wir seit ewigen Zeiten ohne jemals ein Problem damit zu haben.
Da nur zeilenweise eingelesen wird und auch wieder zeilenweise exportiert wird,
klappt das auch mit GB-Dateien einwandfrei.
Läuft natürlich etwas "träger" aber dafür ebenso kein relevanter Speicherbedarf

Code: Alles auswählen

hcr:=chr(13)+chr(10)
c_impdatei:="MUSTER_IMPORTDATEI.CSV"
c_expdatei:="MUSTER_EXPORTDATEI.CSV"
strfile("",c_expdatei)

fib_handl:= FOpen( c_impdatei )
do while .t.
   file_zeile:= LOWZEILE( fib_handl )
   if file_zeile==chr(0)   // Dateiende
      exit
   else
      // Was immer man auch mit der aktuellen Zeile machen will
      // z.B.:
      // strtran(file_zeile,Chr(9),Chr(59))      // Umwandeln
      // strfile(file_zeile+hcr,c_expdatei,.t.)  // In Datei schreiben
      // oder du schreibst das gewünschte ergebnis in eine DBF etc. etc.
   endif
enddo
FClose( fib_handl )


FUNCTION LOWZEILE(lo_handl)
***************************
   private lo_ret,lo_buff,lo_anz,lo_pos
   lo_ret:=""
   lo_buff:=space(255)
   lo_anz:=FRead(lo_handl,@lo_buff,255)
   if lo_anz>0
      lo_buf:f=lo_buff+chr(10)
      lo_pos:=at(chr(10),lo_buff)
      lo_ret:=left(lo_buff,lo_pos-1)
      FSeek(lo_handl, lo_pos-lo_anz , 1)
      Return(CharRem(chr(13)+chr(10)+chr(0),lo_ret))
   else
      return( chr(0) )
   endif
return( chr(0) )

Beste Grüße, Flanneli

[Jan]

Hallo Christof,

meinen Vorschlag mit dem Konvertieren kannst Du da eventuell knicken. Denn ja, Xbase++ kann auch UTF-16 konvertieren per Unicode2Str(). Aber nur wenn die von einem Windows-System geschrieben wurde. Die machen Little Endian. Du schreibst aber das die Daten von einem Großrechner kommen. Wenn der jetzt keinen x86 oder ein paar andere passende Prozessoren nutzt kann das möglicherweise Big Endian sein - was Xbase++ nicht konvertieren kann.

Jan

[Christof]

Hallo Jan,

ich probiere es trotzdem mal. Könnte ja sein, dass es passt.

Außerdem habe ich wohl den "Fehler" bei der Verwendung von Huberts Klasse gefunden. Durch die UTF-16-Codierung wird das erwartete Zeilenende nicht richtig erkannt. Es liegt wohl gar nicht an den einleitenden 2 Zeichen.

Ich experimentiere noch ein bisschen, aber ich glaube, ich bekomme das hin.

VG
Christof

[HaPe]

Hallo Christof !

Wenn der Export einer so großen Datei selten vorkommt, könntest du mittels des Editors Notepad++, die Kodierung in ANSI ändern und erst dann importieren/umwandeln.

[brandelh]

Der "Fehler" ist ein NIL statt einer Zeichenkette, das mag Xbase++ nicht im Zeichenvergleich

du kannst meine Klasse natürlich abändern, und direkt darin verschiedene Umsetzungen machen.

Wie groß ist eigentlich die Datei in Byte wirklich ?

Aber bei einer Dateigröße von ca. 550 MB klappt das halt nicht mehr.

das ist groß, keiner meiner Editoren kann eine solche Datei noch einlesen, wenn ich da was ändern muss, nutze ich PowerBasic und setzte Byte weise um ... das reicht für ein paar Tassen Kaffee

Big und Little Endian, könnte man doch umsetzen (Byte Tausch, aber das dauert sicher viel zu lange).

[HaPe]

Hallo Hubert !

Aber bei einer Dateigröße von ca. 550 MB klappt das halt nicht mehr.

das ist groß, keiner meiner Editoren kann eine solche Datei noch einlesen,

Meine Editoren TSE, Notepad++ und UltraEdit laden ein 500 MB-Datei in 3 bis 4 Sekunden

[Tom]

Vielleicht geht es auch einfacher. Xbase++-Programme können 2GB Speicher verwalten, aber sie reservieren gut ein Drittel davon für Fremdkomponenten, die von der Anwendung bespielt werden. Diesen Anteil kann man auch manuell konfigurieren. Wenn Du ihn reduzierst, klappt es vielleicht auch wieder mit dem alten Verfahren. Mehr dazu in diesem Thread: viewtopic.php?p=144349#p144349

[Marcus Herz]

Hast du es mal mit meinem Vorschlag versucht?
Das ist auf jedemfall der mit dem wenigsten Speicherverbrauch, und der schnellste, weil keine Strings hin und herkopiert wird.
Du brauchst 550 MB dür den Origanlstring und 550 / 2 MB für das Ergebnis.
Da keine Funktionen aufgerufen werden, wird auch nirgendwo eine Arbeitskopie erstellt. Man hat ja da keine Kontrolle, welchen Speicher eine Funktion intern benötigt (z.B. nochmals eine Arbeitskopie)

[AUGE_OHR]

hi Christof,

schon mal versucht die *.CSV in EXCEL zu importieren

aus EXCEL bekommst du die Daten dann in eine *.DBF

[HaPe]

Hallo Jimmy !

aus EXCEL bekommst du die Daten dann in eine *.DBF

Da brauchst du aber ein altes Excel, so 2003 oder vielleicht noch 2007.
Später ist der DBF-Filter rausgeflogen.

[AUGE_OHR]

hi HaPe,

ich würde es per ActiveX machen wobei ich gerne Copy / Paste verwende

Code: Alles auswählen

         oWorkBook:workSheets(1):usedRange:Select

         numRows    := oWorkBook:workSheets(1):usedRange:Rows:Count
         numColumns := oWorkBook:workSheets(1):usedRange:Columns:Count

         FOR i := 1 TO numRows
            AADD(aExcel,ARRAY(numColumns))
         NEXT

         cEnde := ZAHL2CHR(numColumns)   // A-Z
         aExcel := oSheet:range( "A1:"+cEnde+LTRIM(STR(numRows)) ):value

Das Array aExcel dann in eine DBF zu überführen sollte kein Problem sein

aber wie schon gesagt mal probieren was Excel aus der *.CSV macht

[Christof]

hi Christof,

schon mal versucht die *.CSV in EXCEL zu importieren

aus EXCEL bekommst du die Daten dann in eine *.DBF

Hallo Jimmy,

erstens hat die Datei mehr als die ca. 1.000.000 Zeilen, die ein Excelsheet derzeit verarbeiten kann und zweitens kann ich mit meiner Excelversion nicht in eine DBF schreiben. Geht m.E. schon länger nicht mehr.
Da ich jetzt immer öfter solche Datenmengen habe, möchte ich natürlich einen Weg finden, der direkt im Programm funktioniert und keine "Umwege" braucht. Trotzdem danke für den Hinweis.

Gruß
Christof

[Christof]

Hallo,

momentan habe ich eine Lösung gefunden, die auf Huberts Klasse basiert. Ich habe ein paar Änderungen machen müssen und bin auch mit dem Ergebnis noch nicht ganz zufrieden, aber das sollte ich hinbekommen. Es geht eigentlich nur noch um so Kleinigkeiten, wie den Fortschritt anzeigen zu können.

@Tom: Auch ein interessanter Hinweis. Den werde ich auf jeden Fall auch mal ausprobieren. Das wäre natürlich am einfachsten, wenn ich im Prinzip alles so lassen könnte, wie bisher.

Danke nochmal an alle, die mitgedacht und Vorschläge unterbreitet habe. Mit Eurer Hilfe hat's funktioniert.

VG
Christof

[Christof]

Hast du es mal mit meinem Vorschlag versucht?
Das ist auf jedemfall der mit dem wenigsten Speicherverbrauch, und der schnellste, weil keine Strings hin und herkopiert wird.
Du brauchst 550 MB dür den Origanlstring und 550 / 2 MB für das Ergebnis.
Da keine Funktionen aufgerufen werden, wird auch nirgendwo eine Arbeitskopie erstellt. Man hat ja da keine Kontrolle, welchen Speicher eine Funktion intern benötigt (z.B. nochmals eine Arbeitskopie)

Hallo Marcus,

ja, habe ich auch probiert. Hat nicht so wirklich auf Anhieb funktioniert und dauerte komischerweise auch seeeeehr lange. Muss ich mir vielleicht nochmal genauer anschauen.

Gruß
Christof

[AUGE_OHR]

hi Christof,

... mehr als die ca. 1.000.000 Zeilen, die ein Excelsheet derzeit verarbeiten kann

du hast Recht das auch die 64 Bit Version von Excel "nur" 1 Millionen ROW kann ...

mir ging es nur um einen Test ob Excel UTF-16 "versteht" denn dadurch entstehen ja erst deine Probleme
natürlich ist das Grund Problem 32 Bit was den vorhandenen RAM begrenzt, aber auch das Xbase++ nicht mit UTF-16 umgehen kann

Frage : ist deine *.CSV mit BOM

es gibt ja "UTF16LE" und "UTF16BE"

[Martin_L]

Ich würde das Problem pragmatischer lösen.
So machen wir das inzwischen auch hier in der Firma.
Wenn eine Codierung nicht passt, wird ein externe Tool genommen (cscvt).
Damit kann man fast jede Codierung in das gewünschte konvertieren, und auch noch schnell.

[AUGE_OHR]

hi,

unter harbour kann ich das machen

Code: Alles auswählen

//UTF16LE to UTF8
msginfo ( hb_Translate( filestr ( "utf16le.txt" ), "UTF16LE" ), "UTF16LE TO UTF8" )

//UTF16BE to UTF8
msginfo ( hb_Translate( ByteSwap ( filestr ( "utf16be.txt" ) ), "UTF16LE" ), "UTF16BE TO UTF8" )

Code: Alles auswählen

FUNCTION ByteSwap ( cString )
Local cSwapped := "", nByte, cBytePair
FOR nByte := 1 TO Len ( cString ) STEP 2
    cBytePair  := SUBSTR( cString, nByte, 2 )
    cSwapped   += RIGHT( cBytePair, 1 ) + LEFT( cBytePair, 1 )
NEXT
RETURN cSwapped

und mit einer 64 bit App gibt es auch kein Speicher Problem

aber Alaska meint ja immer noch man käme mit 32 Bit aus ...