Unicode bei Feldsymbolen (UC_OBJECTS_NOT_CONVERTIBLE)
Beitrag
von a-dead-trousers (Top Expert / 4450 / 227 /
1196
)
»
Ja, aber ich glaub, das macht der RFC_READ_TABLE bereits falsch.ewx hat geschrieben: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.
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
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Ja, daran kann ich aber nichts ändern. Kann ja nicht einfach das Datenlement/die Domäne ändern.ewx hat geschrieben: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.
Ja, habe ich jetzt auch erkannt. Wie black_adept bereits schrieb:
Es werden alle Tabellenfelder gelesen, obwohl evtl. nur ein paar übergeben werden sollen.
Es wird dann ein kompletter Tabelleneintrag gelesen und "assigned" (bzw. umgekehrt...).
Das funktioniert eben nicht mehr, sobald Zahlenfelder in der Tabelle enthalten sind:
Schon schwach:black_adept hat geschrieben:der FuBa ist unbrauchbar sobald Zahlenfelder in der Tabelle sind.
Es werden alle Tabellenfelder gelesen, obwohl evtl. nur ein paar übergeben werden sollen.
Es wird dann ein kompletter Tabelleneintrag gelesen und "assigned" (bzw. umgekehrt...).
Das funktioniert eben nicht mehr, sobald Zahlenfelder in der Tabelle enthalten sind:
RFC_READ_TABLE hat geschrieben: assign work to <wa> casting type (query_table).
...
select * from (query_table) into <wa> where (options).
Beitrag
von black_adept (Top Expert / 4131 / 130 /
955
)
»
Hallo zero,
hast du eigentlich mal probiert statt RFC_READ_TABLE den anderen allgemeinen RFC-Tabellenlesebaustein von SAP auszuprobieren? Der hat zwar keine so schöne Möglichkeit Restriktionen mitzugeben, aber da du ja scheinbar sowieso nur die Tabelle in ihrere Gesamtheit auslesen willst scheint das verschmerzbar.
FuBa: RFC_GET_TABLE_ENTRIES
hast du eigentlich mal probiert statt RFC_READ_TABLE den anderen allgemeinen RFC-Tabellenlesebaustein von SAP auszuprobieren? Der hat zwar keine so schöne Möglichkeit Restriktionen mitzugeben, aber da du ja scheinbar sowieso nur die Tabelle in ihrere Gesamtheit auslesen willst scheint das verschmerzbar.
FuBa: RFC_GET_TABLE_ENTRIES
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
zer0
Dieser FuBa hat dasselbe Problem, er übergibt die Daten also CHAR mit einer Limitierung auf 512 Zeichen.black_adept hat geschrieben:Hallo zero,
hast du eigentlich mal probiert statt RFC_READ_TABLE den anderen allgemeinen RFC-Tabellenlesebaustein von SAP auszuprobieren? Der hat zwar keine so schöne Möglichkeit Restriktionen mitzugeben, aber da du ja scheinbar sowieso nur die Tabelle in ihrere Gesamtheit auslesen willst scheint das verschmerzbar.
FuBa: RFC_GET_TABLE_ENTRIES
Ich habe aber jetzt die Erlaubnis bekommen, ein RFC Baustein anzulegen. Wenn ich die Daten als DATA oder ANY zurückgebe, sollte ich diese Probleme umgehen können, oder?
Beitrag
von black_adept (Top Expert / 4131 / 130 /
955
)
»
Hallo zero,
sind die Tabellen die du auslesen willst tatsächlich so breit, dass 512 zeichen nicht ausreichen? Für die T006 z.B. sollte der RFC_GET_TABLE_ENTRIES funktionieren, wo der RFC_READ_TABLE versagt.
Davon abgesehen ist es m.W. nicht erlaubt generische Typen ( type standard table ) im RFC anzugeben, so dass du dir da schon einen Kniff ausdenken musst, wenn du tatsächlich jede beliebige Tabelle von einem System in ein anderes schaufeln willst ohne auf XML-Kovertierung zurückzugreifen.
sind die Tabellen die du auslesen willst tatsächlich so breit, dass 512 zeichen nicht ausreichen? Für die T006 z.B. sollte der RFC_GET_TABLE_ENTRIES funktionieren, wo der RFC_READ_TABLE versagt.
Davon abgesehen ist es m.W. nicht erlaubt generische Typen ( type standard table ) im RFC anzugeben, so dass du dir da schon einen Kniff ausdenken musst, wenn du tatsächlich jede beliebige Tabelle von einem System in ein anderes schaufeln willst ohne auf XML-Kovertierung zurückzugreifen.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
zer0
Naja, die Daten sehen noch schlechter aus als beim RFC_READ_TABLE. Beim RFC_GET_TABLE_ENTRIES bei der Tabelle T006 sehe ich fast nur #-Zeichen.black_adept hat geschrieben:Hallo zero,
sind die Tabellen die du auslesen willst tatsächlich so breit, dass 512 zeichen nicht ausreichen? Für die T006 z.B. sollte der RFC_GET_TABLE_ENTRIES funktionieren, wo der RFC_READ_TABLE versagt.
Davon abgesehen ist es m.W. nicht erlaubt generische Typen ( type standard table ) im RFC anzugeben, so dass du dir da schon einen Kniff ausdenken musst, wenn du tatsächlich jede beliebige Tabelle von einem System in ein anderes schaufeln willst ohne auf XML-Kovertierung zurückzugreifen.
Gibt es denn einen wirklichen Unterschied bei beiden FuBa's?
Bezüglich der Tabellenbreite: In den meisten Fällen reichen 512 Zeichen aus, aber darauf will ich mich eig. nicht verlassen. Und dann bleibt trotzdem noch das Problem mit den CHARS.
Beitrag
von black_adept (Top Expert / 4131 / 130 /
955
)
»
Hi zero,
die #-Zeichen siehst du nur, wenn du den FuBa in der SE37 testest. Probier mal einen echten Aufruf im Programm - da verhalten die sich sehr unterschiedlich.
Wenn du beim Breakpoint mal im Debugger die Tabelle gt_t006 anschaust sollteste du sehen, dass auch Zahlenwerte korrekt übermittelt wurden.
die #-Zeichen siehst du nur, wenn du den FuBa in der SE37 testest. Probier mal einen echten Aufruf im Programm - da verhalten die sich sehr unterschiedlich.
Code: Alles auswählen.
REPORT.
DATA: gt_t006 TYPE STANDARD TABLE OF t006 WITH NON-UNIQUE DEFAULT KEY.
CALL FUNCTION 'RFC_GET_TABLE_ENTRIES'
DESTINATION 'GEHEIMERFCDESTINATION'
EXPORTING
table_name = 'T006'
TABLES
entries = gt_t006
EXCEPTIONS
OTHERS = 1.
BREAK-POINT.Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
zer0
Hast recht, funktioniert echt ganz gut! Ich versteh zwar nicht ganz warum dieser FuBa im Gegensatz zu dem anderen funktioniert, obwohl er die Daten ja auch das TABLINE512 übergibt?black_adept hat geschrieben:Hi zero,
die #-Zeichen siehst du nur, wenn du den FuBa in der SE37 testest. Probier mal einen echten Aufruf im Programm - da verhalten die sich sehr unterschiedlich.Wenn du beim Breakpoint mal im Debugger die Tabelle gt_t006 anschaust sollteste du sehen, dass auch Zahlenwerte korrekt übermittelt wurden.Code: Alles auswählen.
REPORT. DATA: gt_t006 TYPE STANDARD TABLE OF t006 WITH NON-UNIQUE DEFAULT KEY. CALL FUNCTION 'RFC_GET_TABLE_ENTRIES' DESTINATION 'GEHEIMERFCDESTINATION' EXPORTING table_name = 'T006' TABLES entries = gt_t006 EXCEPTIONS OTHERS = 1. BREAK-POINT.
Beitrag
von black_adept (Top Expert / 4131 / 130 /
955
)
»
Ein Handmixer ist kein Auto ist obwohl beide einen Motor haben.zer0 hat geschrieben: Ich versteh zwar nicht ganz warum dieser FuBa im Gegensatz zu dem anderen funktioniert, obwohl er die Daten ja auch das TABLINE512 übergibt?
Das ist aber sehr weit hergeholtblack_adept hat geschrieben:Ein Handmixer ist kein Auto ist obwohl beide einen Motor haben.zer0 hat geschrieben: Ich versteh zwar nicht ganz warum dieser FuBa im Gegensatz zu dem anderen funktioniert, obwohl er die Daten ja auch das TABLINE512 übergibt?
Eine letzte Frage habe ich noch: Wegen der Limitierung auf 512 Zeichen werde ich eine Prüfung einbauen, ob die Tabellenbreite die 512 zeichen überschreitet. Hierfür habe ich 3 mögliche Lösungen:
- FuBa DD_TABL_LENGTH_GET
- CL_ABAP_STRUCTDESCR->LENGTH
- DD03L Tabelle (habe ich bereits schon).
Während der FuBa die Tabellenbreite in Bytes zurückgibt (Datentyp INTLEN, Interne Länge in Bytes), gibt die Klasse CL_ABAP_STRUCTDESCR eine andere Länge aus. Ich glaube das hat mit der Unterschied zwischen Dicytionary-Länge und ABAP-Länge zutun. Welche benötige?
Beitrag
von a-dead-trousers (Top Expert / 4450 / 227 /
1196
)
»
Ich weiß jetzt leider nicht welche der Methoden das brauchbarste Ergebnis liefert.
Am Besten du probierst es anhand einiger Tabellen einfach aus.
DD_TABL_LENGTH_GET sollte eigentlich die Länge auf der Datenbank zurückgeben und die kann nicht nur im Bereich von INTLEN und OUTPUTLEN.
Wenn man sich die Infos in der SE11 anschaut können sich auch die Länge der Struktur im Speicher von der in der Datenbank unterscheiden.
Die CL_ABAP_STRUCTDESCR->LENGTH zeigt wahrscheinlich auch auf die interne Länge im Speicher (also die INTLEN aller Komponenten)
Die DD03L sollte glaub ich in deinem Fall das Mittel der Wahl sein.
lg
ADT
P.S.:
Da Tabellen aber auch Strings enthalten können würde ich persönlich zu keiner der drei raten (interne Länge eines Strings ist z.B. immer 8 = BLOB-Zeiger) sondern lieber einen eigenen RFC-Baustein schreiben, der die Daten z.B. als XML exportiert. Damit gibt es am wenigsten Probleme.
Siehe ABAP Hilfe: CALL TRANSFORMATION ID
Am Besten du probierst es anhand einiger Tabellen einfach aus.
DD_TABL_LENGTH_GET sollte eigentlich die Länge auf der Datenbank zurückgeben und die kann nicht nur im Bereich von INTLEN und OUTPUTLEN.
Wenn man sich die Infos in der SE11 anschaut können sich auch die Länge der Struktur im Speicher von der in der Datenbank unterscheiden.
Die CL_ABAP_STRUCTDESCR->LENGTH zeigt wahrscheinlich auch auf die interne Länge im Speicher (also die INTLEN aller Komponenten)
Die DD03L sollte glaub ich in deinem Fall das Mittel der Wahl sein.
lg
ADT
P.S.:
Da Tabellen aber auch Strings enthalten können würde ich persönlich zu keiner der drei raten (interne Länge eines Strings ist z.B. immer 8 = BLOB-Zeiger) sondern lieber einen eigenen RFC-Baustein schreiben, der die Daten z.B. als XML exportiert. Damit gibt es am wenigsten Probleme.
Siehe ABAP Hilfe: CALL TRANSFORMATION ID
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
zer0
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
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.