Tellerchen58 hat geschrieben:das Feld H-XML kann nicht als XSTRING definiert werden, da ich sonst die Fehlermeldung erhalte, dass an dieser Stelle nur ein zeichenartiges Datenobjekt erlaubt ist (also C, N, D, T oder STRING).
OK, anscheinend gibt es nicht nur unklare Fehlerbeschreibungen, sondern in diesem Falle auch unklare Fragen.
Ich meinte mit meiner Frage vor allem, an welcher Stelle (also bei welcher Anweisung) der Fehler auftrat.
Und, ob es um eine Syntaxfehlermeldung oder einen Laufzeitfehler ging.
Denn den von Dir gezeigten Textausschitten dürfte es eigentlich keinen solchen Fehler geben.
Beim READ kann es nur dann zu einem Laufzeitfehler UC_OBJECTS_NOT_CHARLIKE geben, wenn beim OPEN DATASET nicht BINARY MODE, sondern TEXT MODE benutzt wird.
Sowohl bei LEGACY BINARY MODE als auch bei BINARY MODE (ohne Zusatz LEGACY) sollte das
funktionieren, wenn h-xml vom Typ XTRING ist.
(Einen Fehler kann es da eigentlich nur geben, wenn Du eine riesengroße Datei einlesen willst und vom Workprozess nicht genug Speicher reserviert werden kann.)
Füge doch mal nach READ DATASET eine BREAK-POINT-Anweisung ein (oder setze einen dynamischen Break-Point auf die Anweisung und prozessiere die Anweisung im Einzelschritt (F5).
Danach sollte h-xml mit dem Datei-Inhalt gefüllt sein.
Ich nehme an, du bist in einem System mit Basis-Release, in dem es schon den neuen Debugger gibt.
Dann einfach mal auf den Tab-Reiter "Detailanzeigen" wechseln, als Feldnamen h-xml angeben, Enter drücken, und im dann eingeblendeten Dropdown-Menü für Sicht die Option VAR_XML (XML-Browser) auswählen.
Wenn der Feldinhalt vom h-xml gültiges XML darstellt, dann wird der Inhalt ähnlich wie in einem Browser als XML-Dokument angezeigt.
Ansonsten enthält die Datei höchstwahrscheinlich kein gültiges XML.
h-xml kann man jetzt z.B. unverändert an CALL TRANSFORMATION ... übergeben, um bestimmte Inhalte auszulesen.
Tellerchen58 hat geschrieben:In das Feld H-XML werden die Daten beim READ übergeben.
Auch das war nicht meine Frage.
Sondern: Wer liefert die Datei? Wie wurde sie erstellt? Ist sichergestellt, dass die Datei gültiges XML enthält (z.B. durch Prüfung in verschiedenen Browsern oder anderen Programmen zur XML-validation)?
Es gibt mehr Softwareanbieter als man glauben mag, die versuchen, XML-Dateien per Hand zusammenzustricken und dann so Klopper erzeugen wie unkonvertierte <- oder >-Zeichen in Texteingaben des Benutzers.
Verwendung von UTF-8-codierten Umlauten in XML-Dokumenten, die im Header eine andere Codepage als utf-8 angegeben haben, würde mich da überhaupt nicht wundern.
Solchen Schrott würde ich auch gar nicht erst einzulesen versuchen, sondern auf Lieferung von validem XML bestehen.
Insbesondere wenn die Dateien von verschiedenen Lieferanten kommen, kann es durchaus passieren, dass die Dateien nicht die gleiche Code Page nutzen.
Das ist auch kein Problem, wenn man nicht versucht, sie immer mit der gleichen Code Page im (LEGACY) TEXT MODE einzulesen.
Tellerchen58 hat geschrieben:Die Datei, die wir erhalten ist Unicode und kann auch vom einem beliebigen Parser gelesen werden. In der Datei selber sind alle Zeichen auch sauber zu sehen. Nach dem Einlesen sind sämtliche Sonderzeichen unlesbar. Es ist auch egal, welche Sprache genutzt wird (der Report wird europaweit eingesetzt, also auch für kyrillische Zeichen etc.) Selbst mit ü, ä use. kommt der Report nicht klar.
Statt 'wartet auf Frühpension' steht nach dem Einlesen z.B. 'wartet auf Frühpension' in H-XML.
OK, das 'wartet auf Frühpension' sieht ziemlich eindeutig nach utf-8 aus.
Hast Du die Datei mal im BINARY MODE auf einen PC heruntergeladen und im Notepad nachgesehen, ob im Header auch utf-8 als encoding angegeben ist?
Wenn die Fehlermeldung "nicht zeichenartig" woanders auftritt, bitte noch mal genau beschreiben, was für eine Fehlermeldung das ist und bei welcher Anweisung sie auftritt.