[Gelöst] Erklärung File.LEN + File.TRUNC (im CC)

Hallo und Guten Tag.

Weiß jemand, wie die Funktionen File.LEN und File.POS korrekt zu verwenden sind?

Folgender Fall:
Eine Datei wird neu erstellt mit File.WRITEMODE =TRUE und File.TEXTMODE = TRUE.
Jeder neue <Textteil> wird mit File.SEEK(File.POS-2) und anschließendem File.WRITE(Textteil) an die Datei angehängt, damit diese keine [CR][LF] enthält.
.....Beispiel......
//File.POS vor SEEK = 3330
File.SEEK(File.POS-2);
//File.POS nach SEEK = 3328
File.WRITE(FORMAT(Textteil)); //<Textteil> enthält einen String der Länge 128
//File.POS nach WRITE = 3458 (= 3328 + 128 + 1[CR] + 1[LF])
.....

FRAGEN:
(1)
Warum liefert File.LEN jetzt den Wert 2048 und NICHT auch 3458? (Es sieht so aus, als würde File.LEN nur die aktuell physische Dateigröße liefern )
(2)
Wie bekomme ich die beiden letzten Zeichen [CR][LF] aus der Datei entfernt, bevor ich sie mit File.CLOSE schließe?
Restriktion: Bei dieser Dateierstellung darf nur 1x File.OPEN und 1x File.CLOSE verwendet werden.
Nicht zu funktionieren scheint:
File.SEEK(Exportfile.POS-2);
File.TRUNC;
File.CLOSE;


DANK an Euch im voraus.

Zuletzt geändert von hwnav am 7. Mai 2012 10:18, insgesamt 3-mal geändert.

Wozu brauchst Du in Deinem Fall File.LEN?

Nachfolgend siehst Du den bisherigen Code, bei dem die Datei noch einmal geöffnet wird und mit Hilfe von File.LEN die beiden letzten Zeichen abgeschnitten werden. Das funktioniert!
Aber ich benötige eine Lösung, die ohne das zweite File.OPEN auskommt.
....
File.CLOSE;
File.OPEN('die gerade erstellte Datei noch einmal öffnen');
File.SEEK(File.LEN-2);
File.TRUNC;
File.CLOSE;

Zuletzt geändert von hwnav am 4. Mai 2012 11:01, insgesamt 2-mal geändert.

Wieso "merkst" Du Dir nicht die POS irgendwo? Eine Datei ist ja in der Regel nicht dauergeöffnet.

File.Pos habe ich ja; aber File.TRUNC funktioniert im ersten Code ganz oben damit nicht; Warum
Ich vermute, dass ab der Position 3458 -2 kein File.TRUNC funktioniert, weil File.LEN zu diesem Zeitpunkt 'erst' die Länge 2048 liefert

Du solltest mal mit einem OutStream experimentieren (write und Writetext) der kann Texte auch ohne CRLF schreiben. Dann benötigst du die ganze Arie mit file.len.. nicht.

Gruß, Fiddi

Danke Fiddi!
Das scheint zu funktionieren - zumindest nach dem, was man in der Hilfe über "OutStream.WRITETEXT()" nachlesen kann. Klingt GUT
-----
Leider handelt es sich um alten umfangreichen Quellcode mit vielen File.Write und File.POS etc., der bei vielen Kunden im Einsatz ist. Einen Umbau auf "OutStream.WRITETEXT()" müsste man einplanen; so nebenbei geht das leider nicht.
Aber Danke nochmals für den Tipp!
gr. hwnav

Danke Fiddi!
Das scheint zu funktionieren - zumindest nach dem, was man in der Hilfe über "OutStream.WRITETEXT()" nachlesen kann. Klingt GUT
-----
Leider handelt es sich um alten umfangreichen Quellcode mit vielen File.Write und File.POS etc., der bei vielen Kunden im Einsatz ist. Einen Umbau auf "OutStream.WRITETEXT()" müsste man einplanen; so nebenbei geht das leider nicht.
Aber Danke nochmals für den Tipp!
gr. hwnav

Wenn ich das so durchlese, und bedenke, dass bereits einiges zu File.LEN und File.TRUNC gesagt wurde.
Du sogar selbst vermutlich die richtige Erklärung gegeben hast warum du Datei in deinem Codebeispiel doppelt öffnen musst, verstehe ich das NICHT vor dem Thema nicht.

Sobald man die Datei nicht wieder schließt gibt es für File.LEN eben keine aktuellen Werte.
Aus dem selben Grund geht das File.TRUNC dann auch nicht.

Warum kannst du eigentlich die Datei nicht einfach mit CLOSE schliessen und danach wieder mit OPEN öffenen?
Andernfalls sehe ich auch nur den Weg mit OutStream, was in diesem Fall eigentlich auch eleganter wäre, als immer mit File.POS-2 zu arbeiten.

mfg,
winfy

Sobald man die Datei nicht wieder schließt gibt es für File.LEN eben keine aktuellen Werte.
Aus dem selben Grund geht das File.TRUNC dann auch nicht.

Warum kannst du eigentlich die Datei nicht einfach mit CLOSE schliessen und danach wieder mit OPEN öffenen?
Andernfalls sehe ich auch nur den Weg mit OutStream, was in diesem Fall eigentlich auch eleganter wäre, als immer mit File.POS-2 zu arbeiten.

Wenn ich das richtig verfolgt habe geht er derzeit genau den Weg den du vorschlägst und möchte hier nun optimieren.
Die Erklärung die du gibst hat er selbst ja vermutet und jetzt dann auch bestätigt bekommen. ;)
Bleibt mein Erstaunen über das NICHT gelöst.

Für mich bleibt interessehalber noch die Frage:

Warum kannst du eigentlich die Datei nicht einfach mit CLOSE schliessen und danach wieder mit OPEN öffenen?

mfg,
winfy

Für mich bleibt interessehalber noch die Frage:

Warum kannst du eigentlich die Datei nicht einfach mit CLOSE schliessen und danach wieder mit OPEN öffenen?

mfg,
winfy

Mal so als Vermutung in den Raum geworfen:
Verdoppelung der Lese und Schreibzugriffe.
Bei einem File egal, bei einem Batch über ein paar hundert Files läppert sich das.

Hallo McClane, Danjo und winfy,

Fiddi hat mitgeteilt, wie man "mein" Problem grundsätzlich umgehen kann. Das sieht gut aus, kann aber nicht sofort - Umprogrammieren auf "OutStream.WriteText()" - umgestellt werden.

Daher hoffe ich, dass es noch eine weitere Lösung für mein geschildertes Problem gibt.
Vor allem verstehe ich nicht, warum im eingangs gezeigten Beispiel (s. o.) die Funktion File.LEN den Wert 2048 liefert. Der ist m. E. falsch.

Warum nur 1x File.CLOSE()?
Erklärung:
Die Datei wird auf einem DFS (Distributed File System) erstellt. Dabei laufen ständig im Hintergrund Replikationsprozesse, die Veränderungen sofort verarbeiten und abgleichen.
Zwischen dem File.CLOSE und dem erneuten File.OPEN hat der Replikationsprozess die Möglichkeit, die Datei für sich zu "sperren", obwohl sie im NAV noch nicht wirklich fertiggesellt ist. Dann führt File.OPEN(...) zur Fehlermeldung "Sie können zurzeit nicht auf die Datei <...> zugreifen, da sie von einem anderen Programm benutzt oder verändert wird.".
Das Problem soll gelöst werden, indem die Dateierstellung nach dem ersten File.CLOSE auch inhaltlich tatsächlich abgeschlossen ist.

Das zweite File.OPEN erfolgt, weil sich SCHEINBAR nur über den nachfolg. Code die beiden letzten [CR][LF] entfernen lassen.
(ZIEL: Die Datei darf KEINE [CR][LF]-Zeichen enthalten!)
.....
File.CLOSE;
File.OPEN('die gerade erstellte Datei noch einmal öffnen');
File.SEEK(File.LEN-2);
File.TRUNC;
File.CLOSE;

Ich mag das nicht so recht glauben und frage mich, warum der nachfolg. Code nicht das gleiche Ergebnis liefert:
.....
File.WRITE(Textteil);
File.SEEK(File.POS-2);
File.TRUNC;
File.CLOSE;
//File.OPEN('die gerade erstellte Datei noch einmal öffnen');
//File.SEEK(File.LEN-2);
//File.TRUNC;
//File.CLOSE;

Detailliertere Infos zu LEN und TRUNC kann ich in der NAV-Hilfe nicht finden.