ewx hat geschrieben: Zudem würde ich mir hier echt mal weniger Polemik wünschen.
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel
Nein, das ist der Unterschied zwischen dem Rat an einen Entwickler mit 30 Jahren Erfahrung (grob geschätzt), bei dem ich weiß, dass er weiß, was er tut -- und dem Kommentar, dies jemandem zu raten, der die Anweisung nicht kennt und kaum beurteilen kann.DeathAndPain hat geschrieben:Ralf, Du sagst auf der einen Seite, dass man die Anweisung trotz der Obsolet-Kennzeichnung ja dennoch nutzen könne (Apr 18, 2018 10:05), um dann aber im nächsten Atemzug zu sagen, dass dies ein "fragwürdiger Rat" sei. (Apr 18, 2018 11:38) Du musst doch merken, dass Du Dir damit selbst widersprichst!?
Mag sein, aberDeathAndPain hat geschrieben:Deine Behauptung vom Apr 18, 2018 11:38, man könne alles auch mit gültigen Anweisungen lösen, ist gleichfalls fragwürdig, da dies eben nur mit extrem umständlichem und aufgeblähtem Code zu machen ist. Es gibt zahlreiche originale SAP-Tabellen, die von ihrem Aufbau her dem DO...VARYING-Befehl auf den Leib geschrieben sind. Ich habe einige aus dem HCM-Modul genannt; black_adept hat weitere aus anderen Modulen hinzugefügt.
diese Behauptung habe ich nie getroffen. Wo willst du das gelesen haben? Kein Wunder, dass du die Stelle nicht belegt hast im Gegensatz zu allen anderen.DeathAndPain hat geschrieben:Die Behauptung, der Befehl sei nutzlos, ist insofern nicht zu halten.
Das ist eine Entscheidung, die der Hersteller treffen muss. Er hat sich dafür entschieden, einen anderen Weg zu gehen (Stichwort Speicherabbild-Abstraktion) und die Anweisung als obsolet zu kennzeichnen.DeathAndPain hat geschrieben:Wenn er Probleme mit alignment gaps hat, dann müssen diese halt (im Kernel) gelöst werden.
Würde der LOOP massive Probleme verursachen, könnte man darüber nachdenken, richtig. Das ist aber nicht der Fall, also ist die Diskussion überflüssig.DeathAndPain hat geschrieben:Das ist, als wenn ich sage, lasst uns den LOOP-Befehl als obsolet markieren. Man braucht ihn ja nicht; seine Funktionalität lässt sich problemlos mit einer WHILE-Schleife und einer selbstdefinierten Zählvariable nachbilden.
Hier: "So wichtig kann sie also nicht sein." (Apr 18, 2018 10:43)Ralf hat geschrieben:DeathAndPain hat geschrieben:Die Behauptung, der Befehl sei nutzlos, ist insofern nicht zu halten.
diese Behauptung habe ich nie getroffen. Wo willst du das gelesen haben?
Das wäre ja auch in Ordnung, wenn dieser andere Weg funktionieren würde. Das tut er aber nicht, da er nur einen Teil der DO-VARYING-Funktionalität abdeckt. Genau den Teil aber, den man für die effiziente Programmierung der Behandlung der von black_adept und mir genannten Tabellen benötigt, leistet ASSIGN INCREMENT aber eben nicht! Es ist dafür nicht zu gebrauchen und stellt damit nicht die vorgebliche moderne Alternative zum DO...VARYING dar! Ich würde sogar so weit gehen zu sagen, dass der ASSIGN INCREMENT einen Anwendungsfall abdeckt, den man tatsächlich kaum braucht.Das ist eine Entscheidung, die der Hersteller treffen muss. Er hat sich dafür entschieden, einen anderen Weg zu gehen (Stichwort Speicherabbild-Abstraktion)
Du siehst den Unterschied zwischen den beiden Äußerungen?DeathAndPain hat geschrieben:Hier: "So wichtig kann sie also nicht sein." (Apr 18, 2018 10:43)Ralf hat geschrieben:DeathAndPain hat geschrieben:Die Behauptung, der Befehl sei nutzlos, ist insofern nicht zu halten.
diese Behauptung habe ich nie getroffen. Wo willst du das gelesen haben?
Den Unterschied? Ja. Seine Relevanz? Nein.ralf.wenzel hat geschrieben:Du siehst den Unterschied zwischen den beiden Äußerungen?
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 2):
Daniel • black_adept
A: "Ich finde Geld nicht sooo wichtig. Ich bin immer mit wenig Geld ausgekommen".DeathAndPain hat geschrieben:Den Unterschied? Ja. Seine Relevanz? Nein.ralf.wenzel hat geschrieben:Du siehst den Unterschied zwischen den beiden Äußerungen?
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel
Code: Alles auswählen.
TYPES: BEGIN OF substruc,
bezeichnung(10) TYPE c,
wert TYPE i,
END OF substruc.
TYPES: BEGIN OF beispiel2.
INCLUDE TYPE substruc AS sub1 RENAMING WITH SUFFIX 1.
INCLUDE TYPE substruc AS sub2 RENAMING WITH SUFFIX 2.
INCLUDE TYPE substruc AS sub3 RENAMING WITH SUFFIX 3.
TYPES: END OF beispiel2.
Code: Alles auswählen.
FIELD-SYMBOLS: <ls_sub> TYPE substruc,
<ls_cast> TYPE beispiel2.
ASSIGN beispiel TO <ls_cast> CASTING.
uline.
DO 3 TIMES.
DATA(lv_index) = sy-index - 1.
ASSIGN <ls_cast>-sub1 INCREMENT lv_index TO <ls_sub>.
CHECK sy-subrc = 0.
WRITE:/ lv_index, <ls_sub>-bezeichnung, <ls_sub>-wert.
ENDDO.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 3):
ralf.wenzel • a-dead-trousers • DeathAndPain
Wie soll das gehen? Du arbeitest mit Unterstrukturen. Einerseits kann man keine strukturierten Datentypen in Datenbanktabellen verwenden,Wenn es sich um eine SAP-DDIC-Tabelle handelt musst du halt das was ich hier im Code geschrieben habe analog im DDIC veranstalten.
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
DeathAndPain
Beispiel ist genau so definiert wie in deinem 1. Post in diesem Thread. Es ist FELDGLEICH zum Feldsymbol, aber nicht Typgleich.DeathAndPain hat geschrieben:I
- Gehe ich richtig in der Annahme, dass das Feld beispiel vom Typ beispiel2 ist? Würde andernfalls der ASSIGN beispiel TO <ls_cast> CASTING. überhaupt funktionieren?
Du arbeitest doch im HR - Schau dir mal die Struktur P1020 an.DeathAndPain hat geschrieben:andererseits braucht man das ja hauptsächlich für Standard-SAP-Tabellen, an denen man nicht herummodifizieren sollte.
Genau deshalb habe ich die Anleitung geschrieben wie man eine "Analogstruktur" erstellt.DeathAndPain hat geschrieben:Wie soll das gehen? Du arbeitest mit Unterstrukturen. Einerseits kann man keine strukturierten Datentypen in Datenbanktabellen verwenden,
Ich verstehe das Token CASTING nicht wirklich. In der Onlinehilfe steht zur Erklärung nur der Satz: "Falls in casting_spec der Zusatz CASTING verwendet wird, wird der Speicherbereich so behandelt, als hätte er den durch CASTING angegebenen Typ." Diesen Satz verstehe ich aber auch nicht; das ist einfach zu knapp erklärt.Beispiel ist genau so definiert wie in deinem 1. Post in diesem Thread. Es ist FELDGLEICH zum Feldsymbol, aber nicht Typgleich.
Code: Alles auswählen.
BEGIN OF beispiel,
wert1(5) type c,
wert2(5) type c,
wert3(5) type c,
END OF beispiel.
Code: Alles auswählen.
TYPES: BEGIN OF substruc,
bezeichnung(10) TYPE c,
wert TYPE i,
END OF substruc.
BEGIN OF beispiel2.
INCLUDE TYPE substruc AS sub1 RENAMING WITH SUFFIX 1.
INCLUDE TYPE substruc AS sub2 RENAMING WITH SUFFIX 2.
INCLUDE TYPE substruc AS sub3 RENAMING WITH SUFFIX 3.
TYPES: END OF beispiel2.
Das ist die von Dir zuerst genannte P1020 auch. Bei HRFPM_FIN_LIST könnte ich mir einen ASSIGN INCREMENT noch vorstellen, da das eine komplett homogene Struktur ist, die gleich mit der ersten Feldgruppe anfängt. Das ist bei P1020 bereits anders. Beide sind aber insofern akademisch, als sie Strukturen und keine DB-Tabellen sind. Wenn, dann müssten wir also über die HRP1020 reden (wobei die sich über die HRI1020 anstelle der P1020 definiert, aber das spielt für unsere Betrachtung keine Rolle).Besseres Beispiel aus dem HR: Struktur HRFPM_FIN_LIST - die ist mit Includes und Gruppennamen