[RTC] XML Parser - Fehler beim Import

Hallo zusammen,

schon vor einiger Zeit hatte ich mal einen Fehler mit dem XML - Parser -> dieser ist aber zum Glück gelöst. Leider tritt auf einmal bei einigen Leuten ein anderes Problem auf:
Die Datei "Dateipfad\Name.xml" konnte nicht importiert werden.

Natürlich tritt das wieder nur im RTC auf. Das seltsame ist daran ist, dass der Kunde damit eine Zeit lang ohne Probleme arbeiten konnte und plötzlich die Meldung kam.


Was mir aufgefallen ist (siehe Screenshot): Es wird ja für jeden Slash ein Umbruch in Meldungen erzeugt -> das kennen wir. Aber vor dem Dateinamen befindet sich eine Leerzeile? Ist hier ein "Doppelslash" vorhanden? Das wäre natürlich dann falsch und diese Datei existiert dann auch nicht und kann deswegen auch natürlich nicht importiert werden. Aber wieso tritt sowas auf einmal auf? Ich hab auch schon an MS Updates gedacht oder ein Build-Update?!

Weiß vielleicht jemand, woran das nun auf einmal liegen könnte?

Vielen Dank und viele Grüße
Andree

Screen_88.gif

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Wenn es ohne Veränderung im NAV-System auf einmal nicht mehr geht, ist mein erster Gedanke meistens ein Windows-Update.
Kann den der User im Explorer auf den Pfad und die Datei zugreifen? Nicht das es hier einfach nur eine Rechteänderung gab die den Benutzer jetzt aussperrt.
Wenn ja, kann auch der User des ServiceTier-Dienstes diese Datei öffnen?

Hallo,

dass mit den Zeilenumbrüchen liegt an der Message. Die interpretiert jeden Backslash als Zeilenumbruch, auch in Pfadnamen.
Hast du mal den XMLDoc.parseError ausgewertet, wenn das Einlesen mit XMLDoc.load False zurück gibt?

Gruß, Fiddi

@Danjo: Die Rechtestruktur habe ich schon einmal angeschaut -> Die funktioniert. Das war auch mein erster Gedanke bei sowas.

@fiddi: Dass der Backslash als Zeilenumbruch interpretiert wird, ist bekannt, aber wenn dort eine Leerzeile auftaucht, müsste dann nicht ein doppelter Backslash vorhanden sein? Und ausgewertet habe ich da noch nichts. Wäre aber dann auch mal eine Idee zu tun.

Grüße
Andree

ass der Backslash als Zeilenumbruch interpretiert wird, ist bekannt, aber wenn dort eine Leerzeile auftaucht, müsste dann nicht ein doppelter Backslash vorhanden sein?

benutzt du ClientTempfileName aus der CU419 "3-Tier Automation Mgt."? Falls ja, die Funktion hat eine "Unschärfe", die bei manchen Systemfunktionen zu Problemen führt:

Code:

ClientFileName := ClientTempPath + '\' + FORMAT(CREATEGUID) + '.' + FileExtension;

korrekt wäre:

Code:

ClientFileName := DELCHR(ClientTempPath,'>','\') + '\' + FORMAT(CREATEGUID) + '.' + FileExtension;

evtl. ist das auch hier das Problem.

Gruß, Fiddi

Die Codeunit benutzen wir in diesem Falle nicht. Aber das ist dennoch schon einmal für anderen Fälle gut zu wissen

Ich habe etwas neues herausgefunden:

Der Parser arbetiet korrekt. Der Befehl "XMLPort.IMPORT" wirft einen Fehler zurück. Das Attribut <currency> wird erwartet und nicht <> ist der Fehler.
Die Datei ist aber vollkommen korrekt aufgebaut.

Nun bin ich völlig verwirrt...

Hast du das mal mit der dazugehörigen XSD oder DTD- Datei verglichen, ob da drin steht, dass <Currency> enthalten sein muss (minoccurs>0)? bzw. Hast du dem XMLPort das gesagt, dass das ein optionales Attribut ist (ich hoffe das geht, ich benutze eigentlich nur MSXML)

Gruß, Fiddi

Die Datei und auch der XML Port sind korrekt eingestellt... Im Classic funktioniert es auch einwandfrei.

Wenn man nach dem Import eines jeden Datensatzes ein Commit einbaut, sieht man auch, dass er JEDE Zeile der XML-Datei korrekt importiert. Nach der letzten möchte der RTC aber scheinbar weiter machen anstatt wieder die einzelnen Elemente zu schließen, wie es die Datei eigentlich vorsieht.

Wir haben beim Kunden derzeit programmiert "IF NOT XMLPort.IMPORT THEN;" -> Die Fehlermeldung also nicht ausgeführt -> Damit kann der Kunde zunächst arbeiten, weil alles korrekt läuft, aber doch finde ich es sehr mysteriös...

kann es sein das auf dem RTC-Server eine andere Schemadatei befindet als auf dem Client?

Gruß, Fiddi

Schamdatei

Schamdatei

:?:

Is Ja gut.

Könnte ich so nun nicht unterschreiben, würde ich aber ausschließen, da es in einer Standard-Cronus-DB beim Partner auch nachstellbar ist. Hier funktionierte es vorher auch.

Also ich würde es mittlerweile fast irgendwie auf die Build schieben wollen. Weil wieso kann es sonst sein, dass es bei uns und auch bei vielen weiteren Kunden reibungslos funktioniert und nun auf einmal so ein Fehler auftritt, der eigentlich gar nicht da sein dürfte, weil alles korrekt ist.

Schreit das nicht schon fast nach einem Case bei Microsoft?

Es wird ja nicht euer einziger Kunde auf diesem Buildstand sein?

da es in einer Standard-Cronus-DB beim Partner auch nachstellbar ist

Hast du eine Installation mit dem Client auf dem Middle- Tier oder läuft/lief der Client auf einem separaten Rechner?

Gruß, Fiddi

Beides.

Der nachgestellte Fall ist alles auf einem Rechner. Der Original aufgetrene Fall ist mit einem klassischen Server als Middle-Tier.

Der Original aufgetrene Fall ist mit einem klassischen Server als Middle-Tier.

Eben. Bitte auch mal mit abgesetztem Client prüfen. Bin da auch schon oft reingefallen. Ist das evtl. auch der Grund, warum das bei eurem Kunden nicht mehr läuft?

Gruß, fiddi

Der Kunde prüft noch einmal bei sich alles und versucht auch selbst noch einmal was. Wir konnte es unter keiner Konstellation nachstellen oder herausfinden, wieso der IMPORT trotz vollständigem und korrektem Import ein FALSE zurück gibt. Völlig merkwürdig....


Sobald es etwas neues gibt, melde ich mich ...