Seite 2 von 3

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 15:24
von Manfred
Excel?

Jimmy, Excel kommt doch nicht an 900.000 Zeilen dran. Und DBF Dateien? Da arbeitet doch heute eh keiner mehr mit außer uns einsame Exoten.

Bisher wird die ja immer noch über ein PHP Script umgewandelt in eine DBF, aber das will ich in meine Hände nehmen. Das ist zuviel gewurstel bis zum Ziel. Außerdem ist das Thema als solches hier schon ausgiebig besprochen worden. Du hattest auch schon mal einen versuch gestartet, dass über Arrays zu lösen. Du erinnerst Dich?

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 15:34
von Jan
Manfred,

WENN Du das letzendlich doch über ein Array lösen solltest: Das geht nicht mit den bisherigen Xbase++-Mitteln. Du hast zu viele Array-Elemente. Ich hab da auch mal mit gekämpft, und dann von Alaska eine neue dll erhalten, mit der ich die benötigten Handles hochsetzen kann. Ich geb Dir da dann gerne die notwendigen Infos.

Jan

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 15:53
von brandelh
Hi,

es ist schlicht nicht sinnvoll, das über ein Array auch nur zu versuchen ZU VIELE DATEN !!!

Dateien bis 1 GB kann ich hier auf meinem Arbeitsplatzrechner (2 GB RAM + Auslagerungsdatei) sowohl mit memoread() als auch mit meinem MED Texteditor öffnen,
das dauert aber einige Sekunden. Das tue ich aber nur um mir einen groben Überblick zu verschaffen und einige Fehler zu korrigieren.

1. Fehler: FESTE SATZLÄNGE, obwohl hinten 50 Blanks zuviel sind. MED habe ich eingestellt, dass er diese löscht.

So bleiben in 10 Sekunden von z.B. aktuellen 500 MB gerade noch 250 übrig - hängt natürlich vom Inhalt ab ;-)

2. Fehler, besser Problem UNIX Dateien haben kein CRLF, sondern nur ein LF (oder war es nur CR ?)

Auch das kann ich mit MED korrigieren. Kleine Dateien auch mit der folgenden Memoread() ff. Methode.
FReadStr() hat hier schlicht kein passendes Zeilenende, da der nach CRLF sucht.

3. Fehler: Reine Daten enthalten keine chr(0) Zeichen ... außer wenn Sie vom Großrechner kommen und gepackte Zahlenfelder enthalten haben.

Hier nutze ich bis etwa 500 MB memoread(), StrTran(,chr(0)," "), Str2Disk() und kann danach die Datei mit FReadStr() ganz gemütlich einlesen ;-)

Alles was größer ist, kann man mit 4 KB Häppchen fopen(), fRead() etc. einlesen und verarbeiten.
Hierbei muss man darauf achten, dass man möglichst wenig Strings umkopiert, sondern mit Zeigern (nPosVon, nPosBis) arbeitet.

Wenn ich allerdings eine Riesendatei mit Schrott habe, die nur ab und an einen brauchbaren Inhalt hat (z.B. Batchprotokolle),
dann nehme ich PowerBasic PBCC (die Textversion), mit Basic ist die Verarbeitung von Textdateien zeilenweise einfach deutlich einfacher, schneller und sicherer ;-)

Das geht übrigens auch als "Filter" wie früher von DOS her bekannt.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 15:57
von Manfred
Mit Arrays habe ich überhaupt nicht vor zu arbeiten. Das Thema hatten wir doch schon.

Ich werde es häppchenweise machen. Das scheint mir die ideale Lösung zu sein. Will nur hoffen, dass ich evtl. Müll entdecke und entsprechende behandeln kann.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 16:04
von brandelh
Hi,

ich hatte oben noch etwas geändert, du must auf jeden Fall die Datei untersuchen:

Code: Alles auswählen

cTxt := fread(nH,500) // 500 Byte lesen
do case
    case chr(0) $ cTxt
          ...  rechne mit dem Schlimmsten ...
    case chr(13)+chr(10)  $ cTxt
          ... normale PC - Textdatei
    case chr(13) .or. chr(10)
          ... UNIX Spezial, umwandeln.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 16:42
von Herbert
AUGE_OHR hat geschrieben:kannst du die nicht gleich als DBF oder Excel Tabelle bekommen ... ?
Als Excel müsste auch konvertiert werden.
So oder so: Es muss ein einheitliches Schema geben, um einen neuen Datensatz für das Append in der zu füllenden DBF geben.
Abschliessend mit FPOS und FSEEK und Stringbehandlung durchgehen. ist dann nicht schierig zu lösen.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 16:48
von Manfred
Hi Herbert,

aus welcher magischen Dose hast Du denn FPos gezaubert?

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 16:53
von Martin Altmann
Er meint F_POS. Schau mal in der Hilfe zu FSeek()

Viele Grüße,
Martin

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 16:56
von Manfred
Alles klar,

so schlau war ich nicht. :o

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 19:21
von AUGE_OHR
hi,

ok ... mit "Excel" etc. meinte ich nur ein "anderes" Format wo man beim "öffnen" schon merkt ob die Datei in Ordnung ist.

@Manfred : bekommst du die "Text" Datei den wenigstens als ZIP oder mit CRC-Summe etc ?

wenn ich es richtig verstanden habe, hattest du es auch mit "kleineren" Datein versucht ... sind denn "die" Daten ok ?

... irgendwie erinnert mich das an "Modem" Zeiten wo solche "Text" Daten Mengen übermittelt wurden und beim Empfänger immer "irgendwo" ein "Übertragungs-Fehler" war.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 19:27
von Manfred
Die Daten werden aus einem anderen Programm als Textdatei exportiert. Das geht nur komplett, oder gar nicht. Dann werden die gezippt, damit ich die geschickt bekommen kann, in einer vernünftigen Zeit.

Ich habe das mal mit verschiedenen Größen probiert. Es "knallt" schon früher, als bei 2 GB. Irgendwo ist da halt der Wurm drin. Aber glücklicherweise kann das etwas warten. Die Daten werden ja momentan per PHP umgewandelt und das genügt erstmal. Ich beschäftigen mich im Moment mit einem anderen Teil des Programms, bis ich wieder den nötigen Nerv habe mich mit der Konvertierung auseinanderzusetzen.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 19:40
von AUGE_OHR
Manfred hat geschrieben:Die Daten werden aus einem anderen Programm als Textdatei exportiert. Das geht nur komplett, oder gar nicht. Dann werden die gezippt, damit ich die geschickt bekommen kann, in einer vernünftigen Zeit.
... und wer sagt dir das dass "anderen Programm" die Textdatei "richtig" erstellt ?
Manfred hat geschrieben:Ich habe das mal mit verschiedenen Größen probiert. Es "knallt" schon früher, als bei 2 GB. Irgendwo ist da halt der Wurm drin.
das ist das was ich mit "falschem" Export meine.
Manfred hat geschrieben:Die Daten werden ja momentan per PHP umgewandelt und das genügt erstmal.
hm ... mit PHP funktioniert die Text Datei ?
wird die Textdatei "lokal" auf dem selben PC "verarbeitet" ?

schon mal MemoRead() versucht ... es geht nur darum "ob" man mit MemoRead() so eine Textdatei "einlesen" kann.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 19:44
von Manfred
das die richtig erstellt wird, sagt mir (leider) keiner. Da denke ich ja auch die ganze Zeit dran. :(

Ich habe versucht die Datei mit Textpad, OO Writer zu öffnen. Alle Programme, die in der Lage wäre die Datei komplett zu lesen, kacken ab. Die Editoren, die nicht alles packen, öffnen die Datei, aber zeigen nur einen Teil an.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 19:59
von AUGE_OHR
und was ist mit MemoRead() ?

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 20:05
von Manfred
liefert einen leeren String, bzw. ""

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 20:08
von Jan
Nanu? Aus der Onlinehilfe:
Wenn <cFilename> einen ungültigen Dateinamen enthält oder nicht gefunden wurde, gibt MemoRead() ein Null-Zeichen ("") zurück.
Aber wenn der wirklich falsch wäre, dann würden doch all die anderen Versuche auch ins Leere laufen ...

Jan

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 20:14
von Manfred
Stimmt. Und egal, was ich da angebe, es gibt immer einen Leerstring. Au man, der Tag hätte so schön enden können.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 20:32
von AUGE_OHR
Manfred hat geschrieben:Stimmt. Und egal, was ich da angebe, es gibt immer einen Leerstring.
äh ... em ... und was ergibt den bei dir FILE() oder FOpen() ?

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 21:56
von Herbert
Zum einen: Prüft dein Datenlieferant auf Integrität der Daten?
Mir ist immer noch schleierhaft, warum die so gross sein soll...

Zum anderen: Manfred, hast du die Bedingungen von Hubert testweise versucht? Also "schwierige" Zeichen geprüft und ev geändert oder entfernt?

Manfred, noch ein paar Fragen:
Du kannst bis zu einem gewissen Punkt einlesen.
Kriterien beim Einlesen?
Haben die "Recordinformationen" in der Datei eine fixe Länge?

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Mi, 16. Feb 2011 22:04
von brandelh
Hallo Manfred,

liest du eigentlich was ich schreibe ? ;-)

1. Wieviele Byte hat die Datei unkomprimiert genau ?
2. Versuche es mit diesem Editor (ich nutze die 3er Version ...) - da gibt es eine kostenlose Testversion :-) :

:arrow: http://www.med-editor.com/

Bei 2 GB RAM sollten 1 GB Dateien möglich sein - meine letzten Hostdinos sind aber schon ne Weile her, aktuell komme ich nur auf 300.000.000 Byte ;-)

3. Wenn du es nicht hinbekommst, könnte ich für Umforumgen eine PowerBasic als EXE mit Quellcode liefern.

So könnte man das Dateiformat angleichen.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Do, 17. Feb 2011 7:31
von Koverhage
Manfred,

ich glaube Tom hatte das schon vorgeschlagen. Jeder Hex Editor
zeigt Dir die Datei an (unter DOS auch das gute alte LIST).
Du kannst dann suchen, wo z.b. das erste Chr(0) vorkommt.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Do, 17. Feb 2011 8:11
von brandelh
Hi,

hatte ich erwähnt, das MED eine Datei die chr(0) enthält als HEX-Editor anzeigt 8)

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Do, 17. Feb 2011 8:29
von Manfred
Jetzt geht es aber rund....

Also, laßt uns doch erstmal die Sache mit dem Chr(0) klären.

So wie ich es verstehe, ist dann Ende, aber kein Programmabbruch. Sehe ich das richtig?

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Do, 17. Feb 2011 8:31
von Koverhage
wer auch immer, aber damit müsste es relativ schnell feststellbar sein, wo das Problem liegt.

Oder ein read von z.B. 64000 bytes und den entsprechenden Satzzeiger (gelesene Bytes gesamt)
anzeigen.

Re: Wo liegt denn jetzt die max. Größe bei FReadStr() ?

Verfasst: Do, 17. Feb 2011 8:34
von Koverhage
Manfred,

chr(0) dürfte nicht das Problem sein, ich lese auch mit fread z.B. XML
Dateien ein, die CHR(0) enthalten. Da gibt es keine Probleme.
Bitte beachten: Nur bei Freadstr vielleicht, mit dem normalen Fread
ist bei chr(0) nicht Ende.