Unicode bei Feldsymbolen (UC_OBJECTS_NOT_CONVERTIBLE)
Hallo,
ich lese dynamisch eine Tabelle aus einem anderen System über RFC_READ_TABLE. Da ich die Tabelle vorher nicht kenne erstelle ich mir zur Laufzeit ein Feldsymbol mit dem folgenden Code. Wenn ich das ganze mit der Tabelle T024L teste funktioniert es eiwandfrei. Bei der Tabelle T006 bekomme ich beim zuweisen mittels = oder MOVE den Fehler OBJECTS_TABLES_NOT_COMPATIBLE. Wechsle ich auf eine zeilenweise Zurweisung bekomme ich UC_OBJECTS_NOT_CONVERTIBLE.
Das es irgendetwas mit Unicode zutun hat weiß ich mittlerweile, doch eine Lösung habe ich immer noch nicht
ich lese dynamisch eine Tabelle aus einem anderen System über RFC_READ_TABLE. Da ich die Tabelle vorher nicht kenne erstelle ich mir zur Laufzeit ein Feldsymbol mit dem folgenden Code. Wenn ich das ganze mit der Tabelle T024L teste funktioniert es eiwandfrei. Bei der Tabelle T006 bekomme ich beim zuweisen mittels = oder MOVE den Fehler OBJECTS_TABLES_NOT_COMPATIBLE. Wechsle ich auf eine zeilenweise Zurweisung bekomme ich UC_OBJECTS_NOT_CONVERTIBLE.
Das es irgendetwas mit Unicode zutun hat weiß ich mittlerweile, doch eine Lösung habe ich immer noch nicht
Code: Alles auswählen.
data: lt_data type table of tab512,
ls_data type tab512.
data: dref type ref to data.
try.
create data dref type standard table of (gv_tabname_target)
with non-unique default key.
assign dref->* to <table_target>.
call function 'RFC_READ_TABLE' destination gv_rfc_target
exporting
query_table = gv_tabname_target
tables
data = lt_data
exceptions
table_not_available = 1
table_without_data = 2
option_not_valid = 3
field_not_valid = 4
not_authorized = 5
data_buffer_exceeded = 6
others = 7.
if sy-subrc <> 0.
* ...
endif.
if lt_data is initial.
* ...
endif.
*=> FEHLER
move lt_data to <table_target>.
* <table_target> = lt_data.
catch cx_sy_create_data_error.
* Fehlerbehandlung
endtry.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4450 / 227 /
1196
)
»
Klar, dass das nicht funktionieren wird:
- T006 enthält nicht nur Zeichenartige Felder
- T024L enthält nur zeichenartige Felder
Damit du das ganze in eine typisierte Tabelle schaufeln kannst, musst du dir die Daten irgendwie umwandeln.
Am Besten du arbeitest mit den Informationen aus FIELDS in der Übergabestruktur.
Daraus kannst du dir die einzelnen Positionen der Datenfelder innerhalb der TAB512 Struktur ermitteln.
Alternativ kannst du auch mit dem DELIMITER-Parameter arbeiten.
Wobei ich hier aufapssen würde, da ein zu allgemeiner Delimiter durchaus auch in den Daten selber vorkommen kann.
lg ADT.
- T006 enthält nicht nur Zeichenartige Felder
- T024L enthält nur zeichenartige Felder
Damit du das ganze in eine typisierte Tabelle schaufeln kannst, musst du dir die Daten irgendwie umwandeln.
Am Besten du arbeitest mit den Informationen aus FIELDS in der Übergabestruktur.
Daraus kannst du dir die einzelnen Positionen der Datenfelder innerhalb der TAB512 Struktur ermitteln.
Alternativ kannst du auch mit dem DELIMITER-Parameter arbeiten.
Wobei ich hier aufapssen würde, da ein zu allgemeiner Delimiter durchaus auch in den Daten selber vorkommen kann.
lg ADT.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4450 / 227 /
1196
)
»
Werd mir die Lösung mal vormerkenewx hat geschrieben:http://tricktresor.de/content/index.php ... 27&aID=387
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Den Link habe ich auch schon gefunden, jedoch wird in diesem Fall eine lokal definierte Struktur für das Cating verwendet. Ich habe es versucht auf mich zu übertragen, habe es aber bisher nicht geschafft.ewx hat geschrieben:http://tricktresor.de/content/index.php ... 27&aID=387
1) EDIT: probiere ich mal ausa-dead-trousers hat geschrieben:Klar, dass das nicht funktionieren wird:
- T006 enthält nicht nur Zeichenartige Felder
- T024L enthält nur zeichenartige Felder
Damit du das ganze in eine typisierte Tabelle schaufeln kannst, musst du dir die Daten irgendwie umwandeln.
Am Besten du arbeitest mit den Informationen aus FIELDS in der Übergabestruktur.
Daraus kannst du dir die einzelnen Positionen der Datenfelder innerhalb der TAB512 Struktur ermitteln.
Alternativ kannst du auch mit dem DELIMITER-Parameter arbeiten.
Wobei ich hier aufapssen würde, da ein zu allgemeiner Delimiter durchaus auch in den Daten selber vorkommen kann.
lg ADT.
2) Zu welchem Delimeter würdest du raten?
Zuletzt geändert von zer0 am 14.03.2013 14:36, insgesamt 1-mal geändert.
Beitrag
von black_adept (Top Expert / 4131 / 130 /
955
)
»
Der Link ist wirklich interessant - aber seid ihr sicher, dass das überhaupt eine Lösung des Problems ist, bei dem es um einen RFC-Zugriff via RFC_READ_TABLE auf eine Tabelle geht?a-dead-trousers hat geschrieben:Werd mir die Lösung mal vormerkenewx hat geschrieben:http://tricktresor.de/content/index.php ... 27&aID=387
Abgesehen vom verwendeten RFC-Baustein: So ein FuBa baut eine Ausgabestruktur auf und schreibt die Inhalte der gelesenen Werte in eine Zeile bzw. liefert eine Bytfolge zurück. Wenn nun das Quell- und Zielsystem unterschiedliche Unicodeeinstellungen gelten interpretiert das empfangende System die Bytefolge anders als das abgebende System.
Damit die RFC-Übertragung funktioniert müsste die im Zielsystem dynamisch aufgebaute Tabelle die Unicodeeinstellungen des Quellsystems imitieren um die Daten wenigstens in den korrekten Feldern zu empfangen. Und wie das gehen soll wüsste ich ad hoc nicht.
Weiterhin können in der Struktur ja auch Felder enthalten sein, deren Ausrichtung im Speicher Byte- oder Wortgrenzen benötigt. Und die dadurch eventuell nötige Anzahl von Füllbytes könnte sich auch wegen der unterschiedlichen Längen unterscheiden, was zu weiteren Fehlern führen könnte.
Und nun noch mal zu meinem ganz speziellen Freund "RFC_READ_TABLE", den ich aus gewissen Gründen nur noch ganz selten verwende.
Versucht doch mal die Tabelle T006 mit dem RFC_READ_TABLE auszulesen - aber gar nicht über Systemgrenzen hinweg sondern einfach in der SE37 ohne die RFC-Destination zu füllen ( also de facto im selben Mandanten ) und fangt an zu weinen.
Ich kann dir nicht ganz Folgen was du meinst bezüglich des RFC_READ_TABLE?black_adept hat geschrieben:Der Link ist wirklich interessant - aber seid ihr sicher, dass das überhaupt eine Lösung des Problems ist, bei dem es um einen RFC-Zugriff via RFC_READ_TABLE auf eine Tabelle geht?a-dead-trousers hat geschrieben:Werd mir die Lösung mal vormerkenewx hat geschrieben:http://tricktresor.de/content/index.php ... 27&aID=387
Abgesehen vom verwendeten RFC-Baustein: So ein FuBa baut eine Ausgabestruktur auf und schreibt die Inhalte der gelesenen Werte in eine Zeile bzw. liefert eine Bytfolge zurück. Wenn nun das Quell- und Zielsystem unterschiedliche Unicodeeinstellungen gelten interpretiert das empfangende System die Bytefolge anders als das abgebende System.
Damit die RFC-Übertragung funktioniert müsste die im Zielsystem dynamisch aufgebaute Tabelle die Unicodeeinstellungen des Quellsystems imitieren um die Daten wenigstens in den korrekten Feldern zu empfangen. Und wie das gehen soll wüsste ich ad hoc nicht.
Weiterhin können in der Struktur ja auch Felder enthalten sein, deren Ausrichtung im Speicher Byte- oder Wortgrenzen benötigt. Und die dadurch eventuell nötige Anzahl von Füllbytes könnte sich auch wegen der unterschiedlichen Längen unterscheiden, was zu weiteren Fehlern führen könnte.
Und nun noch mal zu meinem ganz speziellen Freund "RFC_READ_TABLE", den ich aus gewissen Gründen nur noch ganz selten verwende.
Versucht doch mal die Tabelle T006 mit dem RFC_READ_TABLE auszulesen - aber gar nicht über Systemgrenzen hinweg sondern einfach in der SE37 ohne die RFC-Destination zu füllen ( also de facto im selben Mandanten ) und fangt an zu weinen.
Die Unicodeeinstellungen sollten eig. auf beiden System gleich sein.
Beitrag
von black_adept (Top Expert / 4131 / 130 /
955
)
»
zer0 hat geschrieben: Ich kann dir nicht ganz Folgen was du meinst bezüglich des RFC_READ_TABLE?
Die Unicodeeinstellungen sollten eig. auf beiden System gleich sein.
Probier es einfach aus - der FuBa ist unbrauchbar sobald Zahlenfelder in der Tabelle sind..black_adept hat geschrieben: Versucht doch mal die Tabelle T006 mit dem RFC_READ_TABLE auszulesen - aber gar nicht über Systemgrenzen hinweg sondern einfach in der SE37 ohne die RFC-Destination zu füllen ( also de facto im selben Mandanten ) und fangt an zu weinen.
Ich glaube ich weiß was du meinst.
Habe mir den folgenden Code erstellt, um das erste Problem zu umgehen.
Bekomme aber nun folgenden Fehler beid er Tabelle T006:
Ich nehme mal an das dies daran liegt, das der FuBa die Zahl konvertiert. Muss ich nun manuell alle Decimals mittels FuBa zurückkonvertieren?
Habe mir den folgenden Code erstellt, um das erste Problem zu umgehen.
Code: Alles auswählen.
loop at lt_data into ls_data.
loop at lt_field into ls_field.
assign component ls_field-fieldname of structure <wa_target> to <comp>.
<comp> = ls_data+ls_field-offset(ls_field-length).
endloop.
insert <wa_target> into table <table_target>.
endloop.
Der Fehler tritt beim Feld ADDKO (ADDKO Datentyp: DEC, Länge: 9, Dezimalstellen: 6) auf.Laufzeitfehler CONVT_NO_NUMBER
Ausnahme CX_SY_CONVERSION_NO_NUMBER
Kurztext
"*3.150000" nicht als Zahl interpretierbar
Ich nehme mal an das dies daran liegt, das der FuBa die Zahl konvertiert. Muss ich nun manuell alle Decimals mittels FuBa zurückkonvertieren?
Beitrag
von a-dead-trousers (Top Expert / 4450 / 227 /
1196
)
»
Schau mal genauer auf die Fehlermeldung:
Ich vermute, du hast bei der Offsetangabe einen Fehler.
Denn Zahlen mit Nachkomma müssen in SAP immer als "Text" im Quellcode eingegeben werden und werden erst vom Interpreter umgewandelt.
lg ADT
Da ist noch ein '*' drinnen."*3.150000" nicht als Zahl interpretierbar
Ich vermute, du hast bei der Offsetangabe einen Fehler.
Denn Zahlen mit Nachkomma müssen in SAP immer als "Text" im Quellcode eingegeben werden und werden erst vom Interpreter umgewandelt.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Nein der Offset stimmt, siehe mein Code oben.a-dead-trousers hat geschrieben:Schau mal genauer auf die Fehlermeldung:Da ist noch ein '*' drinnen."*3.150000" nicht als Zahl interpretierbar
Ich vermute, du hast bei der Offsetangabe einen Fehler.
Denn Zahlen mit Nachkomma müssen in SAP immer als "Text" im Quellcode eingegeben werden und werden erst vom Interpreter umgewandelt.
lg ADT
Ich vermute eher das es am Datentyp des Feldes an dieser Position liegt:
Domäne ADDKO
Datentyp DEC
Zahl der Stellen 9
Dezimalstellen 6
Ausgabelänge 11
Die Ausgabelänge ist auf 11 beschränkt und ich denke das dies den Fehler verursacht.
Beitrag
von a-dead-trousers (Top Expert / 4450 / 227 /
1196
)
»
nein, die länge hat da gar nichts damit zu tun.
Da steht ganz klar am Anfang ein '*'.
Wenn du den weglässt, wird auch der Wert richtig übernommen.
Da steht ganz klar am Anfang ein '*'.
Wenn du den weglässt, wird auch der Wert richtig übernommen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Nein, hab hier mal ein Screenshot gemacht und einen Delimter eingestellt:a-dead-trousers hat geschrieben:nein, die länge hat da gar nichts damit zu tun.
Da steht ganz klar am Anfang ein '*'.
Wenn du den weglässt, wird auch der Wert richtig übernommen.
Dort sieht man ganz klar, das der * zur zahl dazu gehört.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von a-dead-trousers (Top Expert / 4450 / 227 /
1196
)
»
Dann hat der RFC_READ_TABLE irgendwo einen Fehler.
Auch wenn du mit einer Konvertroutine versuchen würdest diese Daten umzuwandeln, funktioniert es wegen des '*' nicht.
Was steht denn eigentlich in der ursprünglichen Tabelle an dieser Stelle drinnen?
Kommt da bei dem '*' nochwas? Im Sinne von zu wenig Platz ('...')
Wenn nicht, dann könntest du versuchen, vor der Konvertierung zu bestimmen um welchen Datentyp es sich handelt und alle Zeichen die nicht dazugehören entfernen.
In etwa so:
Auch wenn du mit einer Konvertroutine versuchen würdest diese Daten umzuwandeln, funktioniert es wegen des '*' nicht.
Was steht denn eigentlich in der ursprünglichen Tabelle an dieser Stelle drinnen?
Kommt da bei dem '*' nochwas? Im Sinne von zu wenig Platz ('...')
Wenn nicht, dann könntest du versuchen, vor der Konvertierung zu bestimmen um welchen Datentyp es sich handelt und alle Zeichen die nicht dazugehören entfernen.
In etwa so:
Code: Alles auswählen.
if ld_type ca 'INFP'. "Integer, Numeric, Float, Packed, usw...
replace all OCCURRENCES of regex '[^0123456789.]' in ld_text with space.
endif.
Zuletzt geändert von a-dead-trousers am 15.03.2013 09:55, insgesamt 1-mal geändert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Dort sieht man auch ganz klar, dass dein Ausgabefeld nur NEUN Stellen hat, obwohl es ELF braucht!zer0 hat geschrieben:Dort sieht man ganz klar, das der * zur zahl dazu gehört.
Das Feld ist zu klein und deswegen steht an erster Stelle das *
Du musst für diesen Baustein den Wert aus OUTPUTLEN nehmen.
Vergleichbare Themen
0
Antw.
Antw.
2492
Views
Views
Unicode-Strings via ABAP-OLE2 to EXCEL (NON-Unicode-SAP-Sys)
von fritz_herma » 15.03.2007 14:17 • Verfasst in ABAP® Core
von fritz_herma » 15.03.2007 14:17 • Verfasst in ABAP® Core
5
Antw.
Antw.
2218
Views
Views
2
Antw.
Antw.
4886
Views
Views
8
Antw.
Antw.
2761
Views
Views
Zuweisung an Felder innerhalb von Feldsymbolen
von Svenson » 01.08.2005 16:05 • Verfasst in ABAP® Core
von Svenson » 01.08.2005 16:05 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.