Dataport - erkennt nächsten Datensatz nicht

Hallo Zusammen,

ich habe ein (kleines) Problem mit einem Dataport.

Hab im Forum dazu gesucht, konnte aber leider keine Lösung finden.
Ich denke aber, dass die Sache für euch Spezialisten kein großes
Problem darstellt.

Ein .NET Programm erzeugt eine Textdatei. Diese soll in das Istmeldungs-
buchunsblatt, per Dataport eingelesen (und später verbucht) werden.

Funktioniert soweit auch gut, aber nur, wenn die Textdatei nur eine Zeile enthält.
Enthält die Textdatei mehr als eine Zeile, erfolt eine Fehlermeldung. Der Dataport
erkennt wohl nicht, wann die neue Zeile bzw. der nächste Datensatz beginnt.

Details:
Navision 2.01 (3.60)

Dataport:
DataiItem : FA Istmeldung Buch.-Blattzeile

Proberties:
FieldStartDelimiter : <None>
FieldEndDelimiter : <None>
Fieldseperator : ;
FileFormat : Variable
RecordSeparator : <<NewLine>>
UseReqForm : Nein
DataItemSeparator : <<NewLine><NewLine>>
TransactionType : <UpdateNoLocks>
Permissions : <Undefined>

Einzulesende Felder:
- "Buch.-Blatt Vorlagenname"
- "Buch.-Blatt Name"
- Buchungsdatum
- "FA-Nr."
- "Artikelnr."
- "Arbeitsgangnr."
- "Fertiggestellte Menge"
- Beendet

Beispiel erzeugte Textdatei (mit zwei Zeilen):

FERTAUFTR ; PRODUKTION ; 21.06.2010 ; FA33100798 ; 421.0078 ; 30 ; 5000 ; Nein
FERTAUFTR ; PRODUKTION ; 21.06.2010 ; FA33100879 ; 423U0100 ; 30 ; 5000 ; Ja

Fehlermenldung:
Die Wahlmöglichkeit ‚ Nein FERTAUFTR ‚ ist nicht vorhanden. Die Wahlmöglichkeiten sind:
Nein, Ja

Weiteres Problem, wird eine neue Textdatei eingelesen und es steht noch eine Zeile im
Buchblatt, wird diese Zeile überschrieben. Neue Zeilen sollten aber angehängt werden.

So, das war’s hoffe ihr Profis könnt mir helfen!

Ich wünsche euch einen schönen sonnigen Tag!

Viele Grüße Horst

Eine Zusatzfräge hätte ich noch

Ist es möglich, (in unserer Navision Version) einen Dataport Zeitgesteuert (regelmäßig)
laufen zu lassen?

Scheint, als würde er den Zeilenumbruch nicht richtig fressen. Ist da am Zeilenende garantiert ein CRLF?

Hallo,

weis nicht genau, was du mit CRLF meinst.

Die Textdatei sieht aus wie oben d.h. die Textdatei enthält 2 Zeilen.
Muss der Line-Feed in der Textdatei noch zusätzlich irgendwie "ausgedrück"
werden?

Gruß
Horst

Der Verdacht liegt nahe, dass das .NET-Programm Steuerzeichen verwendet, die vom Dataport nicht als "Zeilenumbruch" interpretiert werden können.

Du kannst einen ganz einfachen Gegentest machen: Stell dich ans Ende der 1. Zeile und erzeuge mit Enter einen neuen Zeilenumbruch. Lösche danach den ursprünglichen. Lese die Datei nun erneut ein.

Wie McClane schon geschrieben hat muss da sowohl ein CarriageReturn, als auch ein LineFeed am Ende der Zeile stehen.

Zu deiner Zusatzfrage: Ich kenne 2.xx nicht sonderlich gut, aber wenn es den NAS (man braucht hierfür wieder Lizenzen) in dieser Version schon gibt, geht es. Eine andere Möglichkeit ist es, sich einen Verarbeitungskalender zu basteln, welcher sekündlich prüft, ob ein Job ausgeführt werden muss.

Gruß aus dem sonnigen Schwabach,
Sebastian

Nein, muss sie nicht. Üblicherweile besteht ein Zeilenumbruch aus einem CarriageReturnLineFeed, was der Zeichenfolge CHR(13)+CHR(10) entspricht. Da bei dir der RecordSeparator=NewLine ist, erwartet NAV da also "any combination of CR and LF" (zumindest in NAV5).

Möglicherweile schreibt ihr aber nur eines davon in die Textdatei. Du kannst ja mal, wenn sich das nicht klären oder ändern lässt, den RecordSeparator testweise auf "<CR>" oder "<LF>" umstellen.

Hallo Zusammen,

vielen Dank für eure Hilfe und eure Mühe, ich weis das zu schätzen.

Hab etwas gebraucht um eure Vorschläge durchzutesten.

Also, der Reihe nach:

- Der Vorschlag von Natalie, mit dem manuellen Zeilenumbruch hat nicht funktioniert - solange der Record Seperator
auf <<NewLine>> steht.

- Der Vorschlag von McClane hat so funktioniert, dass ich jetzt ein Teilergebnis habe:
- Record Separator = <LF> funktioniert nicht
- Record Separator = <CR> funktioniert!
Es erfolgt jetzt keine Fehlermeldung mehr.
Es wird aber immer nur die erste Zeile der Textdatei ins Buchblatt eingelesen, alle weiteren bleiben leider weiter unberücksichtigt

- Zur Info: Der Code des VB .NET Programms, welcher den Zeilenumbruch erzeugt, sieht folgendermaßen aus:

ObjInDateiSchreiben.Write(BeendetText + Chr(13) + Chr(10))

Erklärung:
ObjInDateiSchreiben = Dies ist ein Objekt vom Typ; Streamwriter
BeendetText = Dies ist eine Stringvariable welche "Ja" oder "Nein" für "Arbeitsgang beendet" entgegennimmt.

- Der Vorschlag von Sebastian Pfliegel hört sich interessant an.
NAS sagt mir aber leider nichts, Wo kann ich sehen, ob es dies in unserer Version gibt?
Verarbeitungskalender hört sich interessant, aber auch kompliziert an

Ich wünsch euch noch "frohes Werken"

Gruß
Horst

Hmmmm, Char13 und Char10 sind korrekt (entspricht CR + LF). Was passiert wenn du die Textdatei einfach mal selbst in Notepad schreibst?

Nochmal zur Zusatzfrage:
Für Verarbeitungskalender oder ähnlichem gibt es auch kostenlose Alternativen (für manche braucht man trotzdem einen NAS und damit auch eine dementprechende Lizenz); hier was ich in sekundenschnelle gefunden habe: Klick mich!
Außerdem standen hier schon mehrere vor diesem Problem, also eine Suche hier sollte dir viele schöne Möglichkeiten zeigen, wie man das Problem lösen kann.

Grüße,
Sebastian

Seltsam. Das, was das Programm schreibt, liest sich ja ganz ok.

Man könnte natürlich testweise noch "<CR/LF>" als RecordSeparator versuchen, aber mir kommt es eher so vor, als müsse der CRLF in VB anders erzeugt werden, oder eure NAV-Version sei buggy.

Wo stecken denn unsere VB-Spezis?

Hallo Sebastian,

vielen Dank für deine schnelle Antwort!

Werd das mit der Textdatei u. Notepad später probieren.

Danke auch für deinen Link, schau mir die Sache ebenfalls später genau an.

Ich muss jetzt außer Haus, kann mich deshalb erst heut Nachmittag wieder um
diesen Vorgang kümmern. Seht es mir deshalb bitte nach, wenn ich erst heut
Nachmittag wieder antworte.

Wüsch euch frohes Schaffen,

viele Grüße
Horst

Man könnte natürlich testweise noch "<CR/LF>" als RecordSeparator versuchen, aber mir kommt es eher so vor, als müsse der CRLF in VB anders erzeugt werden, oder eure NAV-Version sei buggy.

Wo stecken denn unsere VB-Spezis?

Hier ist er :)
Also, wenn man es VB-konform machen will, lautet die Konstante dafür vbCrLf

Ich schlage also vor:

Code:

ObjInDateiSchreiben.Write(BeendetText + vbCrLf)

Gruß,
Sebastian