Schnittstellenstrategie

Das ist ja wirklich praktisch.
Ich bin noch nicht alle Satzarten durch, aber das Längste bislang war 77 Zeichen lang.

Hallo MSNAVLerner,

Ich bin bei deinem Code einfach noch nicht ganz durchgestiegen. Wie würde beispielsweise die READ in Binärversion aussehen bei folgendem Beispiel?

Bezeichnung: Quelle
Länge: 10

Bezeichnung: Ziel
Länge: 10

Bezeichnung: Anlegezeit
Länge: 15

Bezeichnung: Auftragsnr.
Länge: 11

Bezeichnung: Auftragsposnr.
Länge: 3

Code:

ERP       EXTERN    YYYYMMDDHHMMSS A123456789
ERP       EXTERN    YYYYMMDDHHMMSS A123456789 15


In Pseudocode:

MyFile.open(MyFileName);
MyFile.textmode(false);
//Schleife
//erstes Feld ansteuern - nehmen wir YYYYMMDDHHHMMSS, also Offset 20
RecordOffset := MyFile.pos;
MyFile.seek(RecordOffset + 20);
for i := 1 to 15 do
MyFile.read(MyDTString[i]);
//nächstes Feld ansteuern - nehmen wir die 15, also Offset 47
MyFile.seek(RecordOffset + 47);
for i := 1 to 2 do
MyOtherField.read(MyOtherField[i]);
// und so weiter
// zum Schluss CR/LF suchen (bei variabler möglicher länge) oder RecordOffset um Recordlänge plus CR/LF erhöhen
RecordOffset := RecordOffset + 3002;
//Ende Schleife

Die Feldlesefunktion würde ich kapseln, und innerhalb dieser jede Dateioperation mit if not MyFile.EOF() absichern.

LG Jens

Das werde ich mal ausprobieren.
Würde sowas auch gehen? Da fehlt noch, dass er nach Zeile 3000 in der nächsten Textzeile anfängt.

MyFile.OPEN(MyFileName);
MyFile.TEXTMODE(FALSE);
for i := 20 to 35 do
MyFile.READ(MyDTString[i]);
for i : = 36 to 47 do
MyFile.READ(MyAuftragsnrString[i]);
...

Bitte Vollzitate auf die für das Verständnis notwendigen Anteile reduzieren.

Hallo MSNAVLerner,

wichtig ist das Positionieren auf den Feldanfang mit file.seek(offset). Die gekapselte Funktion liefert Dir optimalerweise den Dateiinhalt als String von Anfangsposition für soundsoviel Zeichen zurück. Den Du dann ggf. weiterverarbeitest in das was es wirklich sein soll - Code, Text, Decimal, Integer, Boolean, Date, Time. Der Pseudocode dafür sieht dann so aus:

GetField(TestString,Offset1,Count1);
TestStringverarbeiten1();
GetField(TestString,Offset2,Count2);
TestStringverarbeiten2();
...

Je besser die gekapselte Funktion implementiert ist um so weniger Geraffel hat man ringsherum.

LG Jens

Ja da hast du absolut recht. Die Umwandlung in das passende Format möchte ich auch gekapselt in Unterfunktionen abbilden, damit der Fluss sauber ist.
Kannst mir noch einen Tipp geben, wie ich, nachdem ich an der 3000ten Stelle angekommen bin, in der nächsten Zeile weiter mache?
In meinem Fall hat jede Zeile ganz genau 3000 Zeichen (statisch).

Hallo MSNAVLerner,

wenn Dein Record 3000 Zeichen hat und der Record-Trenner CR/LF ist, beginnt das nächste Record bei 3002. Deswegen die Variable RecordOffset, die halt immer um 3002 hochgezählt wird.

LG Jens

Irgendwas übersehe ich. Die Satzart in der zweiten Zeile findet er nicht.

Code:


    // Startposition
    intAktPosition := filMyFile.POS;
    i := 1;

    // Erste Zeile
    filMyFile.SEEK(intAktPosition + 40);   // Beginn Satzart
    FOR i := 1 TO 9 DO
      filMyFile.READ(txtSatzart[i]);

      MESSAGE(' Er hat den %1 erkannt ', txtSatzart);


    // Zweite Zeile
    j := 1;
    intAktPosition  := intAktPosition + 3002;
    filMyFile.SEEK(intAktPosition + 40);
    FOR j := 1 TO 9 DO
      filMyFile.READ(txtSatzart2[j]);

    MESSAGE(' Er hat den %1 erkannt ', txtSatzart2);


Schnittstellen-Themen, immer wieder ein Spaß.
Ich weis nun, warum es nicht funktioniert. Vermittelt wurde, dass jede Zeile 3000 Zeichen lang ist, dem ist jedoch nicht so.
Es kann bis zu 3000 Zeichen lang sein. In den meisten Fällen ist es unter 1000 Zeichen lang.

Somit mein neuer Plan:
Über Report Files einlesen, nach Satzart suchen und abhängig davon in einer Codeunit die jeweilige Funktion aufrufen. Diese, abhängig davon ober unter 1000 Zeichen lang, arbeitet mit READ-Function oder aber Byteweise-Verarbeitung.