EOF() bei Textdateien [ERLEDIGT]

[Rolf Ramacher]

Hi Manfred,

schau dir mal mein Beispiel an. Dann kannst du in dem Fall cDatenSatz doch mit strtran ersetzen.

[Manfred]

Hi Martin,

ich habe heute wohl zu wenig Nahrung zu mir genommen, ich verstehe den 2.Satz nicht.

[Martin Altmann]

Hallo Manfred,
dann solltest Du das schleunigstens ändern: Guten Appetit!
Habe gerade gesehen, dass mein 2. Satz einen vorwurfsvollen Ton implizeren könnte - war aber ganz anders gemeint!
Was ich sagen wollte:
Wenn Du die Sachen im 1. Satz erledigt hast, kannst Du wie bisher weitermachen, nur mit Datei B - brauchst also ausser dem Namen der zu verarbeitenden Datei an Deinem eigentlichen import nichts ändern (wohlgemerkt, nachdem Du das Suchen und Ersetzen erledigt hast).

Viele Grüße,
Martin

[Manfred]

Hi Martin,

Gut, aber wenn ich den 1.Durchlauf machen muß/soll, dann kann ich auch gleich meine alte Routine wieder einbauen, die spart mir dann den 2. Durchlauf. Denke ich jetzt mal so.

Boh ey, hab ich nen Kohldampf. Das werde ich jetzt mal schnell abstellen.....
Bevor ich hier gar nichts mehr kapiere.

[brandelh]

Hallo Manfred,

überlege doch mal. Du hast ein Importprogramm, das mit sauberen Dateien funktioniert. Und du hast eine unsaubere Datei (damit muss man immer rechnen).

Nun musst du - wie Martin schon sagte - nur die Dateien von eventuellem 'Schmutz' (chr(26) und chr(0) reinigen, wobei du beide durch Blanks ersetzt ( Löschen wäre wohl falsch, da die Satzlänge nicht geändert werden darf !).

Also statt wie bisher:

1.... Dateiauswahl und irgendwas
2. Importroutine(TextDatei)

rufst du nun die Reinigung dazwischen auf:

1.... Dateiauswahl und irgendwas
2. Reinigen mit strtran(cTxt,chr(26),space(1)) ....-> TempTextDatei
3. Importroutine(TempTextDatei)

[Manfred]

Leute,

macht mich jetzt nicht nervös....

1) Die Felder werden mit TAB getrennt und müssen nicht gleich groß sein.
2) Wenn ich doch erstmal die Zeilen durchwusel und nach evtl. defekten Zeichen suche, dann kann ich doch direkt den Rest gleich mitmachen.
3) Warum soll ich dann nochmals umkopieren und dann erneut mit DELDBE öffnen und alles nochmals durchlaufen?
4) Ich wollte doch die DELDBE benutzen weil es so schön einfach ist. Warum das Rad immer wieder neu erfinden.

Meine Frage war doch am Anfang nur, ob einer eine Idee hat woran es liegen kann. Das Problem ist erkannt, es ist ein Schrottzeichen. Jetzt warte ich auf die kalte Ecke aus Hessen was die dazu zu sagen hat.

So hungrig kann ich doch nicht sein, dass ich dass alles hier nicht verstehe.

Was wir noch machen könnten, wäre meinen Quellcode analysieren, ob er überhaupt vernünftig war, als ich zeichenweise durchsucht habe. Ich werde ihn gleich, wenn ich gemampft habe, suchen und dann mal hier einstellen.

Aber nichtsdestotrotz prima, dass ihr so bei der Sache seit....

[Tom]

Hallo, Manfred.

Es wird ein Zeichen als EoF() interpretiert, obwohl das physikalische EoF() noch nicht erreicht ist. Wenn Du die Datei einliest, mit StrTran() (eine Zeile Code!) das Zeichen entfernst und danach das ganze wieder schreibst, was insgesamt drei (!) Zeilen Code wären, müßtest Du am Rest - also am vorhandenen Code - nichts mehr ändern. Das war, was Dir die Jungs zu sagen versucht haben.

[Manfred]

Mooooment,

ich verstehe das jetzt so:

1) Ich öffne die Datei über Lowlevel
2) ich suche und tausche das Zeichen (wenn nötig)
3) schreibe Lowlevel wieder zurück
3a) schließe die Datei wieder
4) Öffne mit DELDBE
5) Mache meine Ding mit Skip usw.
6) schließe wieder...

war das so gemeint?

[brandelh]

Mooooment,

ich verstehe das jetzt so:

1) Ich öffne die Datei über Lowlevel
2) ich suche und tausche das Zeichen (wenn nötig)
3) schreibe Lowlevel wieder zurück
3a) schließe die Datei wieder
4) Öffne mit DELDBE
5) Mache meine Ding mit Skip usw.
6) schließe wieder...

war das so gemeint?

GENAU SO war das gemeint

und anders geht es auch nicht, denn sowohl DELDBE als auch ReadStr() werden NIEMALS nach dem chr(26) weiter lesen

[Manfred]

So, liebe Leute,

vorläufiges Ergebnis:

PDR #5994

[brandelh]

Hi Manfred,

die Beschreibung im PDR sagt doch aus, dass dieses Verhalten (Abbruch bei chr(26) = 0x1A) 'per design' also richtig ist. Somit ist das ein Endergebnis

[Manfred]

Hi Hubert,

hm, ich habe diesen PDR gestern nicht gefunden, weil dort stand, er wäre noch nicht public. Also habe ich ihn auch noch nicht gelesen.

Es geht aber um etwas ganz anderes:

Die Erklärung dazu heißt folgendermaßen (sinngemäß von mir wiedergegeben):

Die Reaktion der Engine ist richtig, aber nicht mehr zeitgemäß, weil dies vor allem da ja Dateien auf File-Systemen
über eine Dateilänge verfügen und nicht wie früher Magnetbänder immer als
Datenstrom gelesen werden müssen um die Größe somit das Ende der
Datei zu erfahren.

Jetzt stellt sich nur die Frage, was passiert nun?

Ich vermute einmal, das das Problem bei einem etwas anderen Handling nicht mehr auftreten wird/würde. Das entscheidet aber Alaska nun selbst, was sie wie lösen werden/möchten.