DO... VARYING vs ASSIGN INCREMENT

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
54 Beiträge • Vorherige Seite 3 von 4 (current) Nächste
54 Beiträge Vorherige Seite 3 von 4 (current) Nächste

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von ewx (Top Expert / 4854 / 313 / 644 ) »
Ja, ich kenne den Befehl.
Ja, ich habe ihn schon mal benutzt.
Und ich finde immer noch, dass er so wichtig nicht ist.
Und immerhin ist das noch meine eigene Meinung und kein Gesetz, das ich verabschieden möchte.

Deswegen noch mal:
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


gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von ralf.wenzel (Top Expert / 3946 / 201 / 281 ) »
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!?
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: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.
Mag sein, aber
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? Kein Wunder, dass du die Stelle nicht belegt hast im Gegensatz zu allen anderen.
DeathAndPain hat geschrieben:Wenn er Probleme mit alignment gaps hat, dann müssen diese halt (im Kernel) gelöst werden.
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: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.
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.



Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von DeathAndPain (Top Expert / 1961 / 261 / 415 ) »
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?
Hier: "So wichtig kann sie also nicht sein." (Apr 18, 2018 10:43)
Das ist eine Entscheidung, die der Hersteller treffen muss. Er hat sich dafür entschieden, einen anderen Weg zu gehen (Stichwort Speicherabbild-Abstraktion)
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.

Ich hatte erst vermutet, dass ich etwas übersehe und daher diesen Thread hier eröffnet. Aber offenbar ist es tatsächlich so.

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von ralf.wenzel (Top Expert / 3946 / 201 / 281 ) »
DeathAndPain hat geschrieben:
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?
Hier: "So wichtig kann sie also nicht sein." (Apr 18, 2018 10:43)
Du siehst den Unterschied zwischen den beiden Äußerungen?


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
Auch den ASSIGN INCREMENT kann man gebrauchen.
Aber halt in ganz anderen Situationen.
Als Ersatz ist er völlig untauglich.

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von DeathAndPain (Top Expert / 1961 / 261 / 415 ) »
ralf.wenzel hat geschrieben:Du siehst den Unterschied zwischen den beiden Äußerungen?
Den Unterschied? Ja. Seine Relevanz? Nein.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 2):
Danielblack_adept


Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von ewx (Top Expert / 4854 / 313 / 644 ) »
DeathAndPain hat geschrieben:
ralf.wenzel hat geschrieben:Du siehst den Unterschied zwischen den beiden Äußerungen?
Den Unterschied? Ja. Seine Relevanz? Nein.
A: "Ich finde Geld nicht sooo wichtig. Ich bin immer mit wenig Geld ausgekommen".
B: "Es gibt zahlreiche Leute, die ständig viel Geld brauchen, deine Behauptung, Geld sei nutzlos ist also nicht zu halten."

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel


Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von black_adept (Top Expert / 4103 / 128 / 945 ) »
@D&P: Noch mal zu der Originalfrage: Wenn du das für eine spezielle SAP-Tabelle häufiger benötigst könntest du auch folgendes machen.
Zunächst baust du dir eine feldgleiche Analogstruktur auf. Für dein Beispiel sähe das so aus:

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.
Beispiel und Beispiel2 sollten jetzt Feldgleich sein - allerdings kannst du die Unterstrukturen nun auch direkt ansprechen. Wenn es sich um eine SAP-DDIC-Tabelle handelt musst du halt das was ich hier im Code geschrieben habe analog im DDIC veranstalten.
Wenn das so weit geschehen ist kannst du die "original"-Struktur auf ein Feldsymbol mit der "modifizierten" Struktur casten und dann doch wieder mit dem ASSIGN INCREMENT arbeiten

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.
Ist halt etwas Initialaufwand - aber danach darfst du mit nicht obsoleten Mitteln endlich das machen, was der "alte" Befehl von Haus aus konnte. Und wenn es sich um eigene Tabellen handelt hast du das Problem mit der Analogstruktur eh nicht, da du dann gleich mittels Include und Gruppenname und Suffix arbeiten kannst.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 3):
ralf.wenzela-dead-trousersDeathAndPain

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von a-dead-trousers (Top Expert / 4414 / 224 / 1186 ) »
@black_adept
Die Includes verwende ich schon seit Jahren, daher ist mir das DO ... VARYING auch noch nie untergekommen bzw. habe ich das nie benötigt.
Das man das auch mit CASTen verwenden kann, auf die Idee bin ich noch gar nicht gekommen. Das eröffnet ganz neue Möglichkeiten, wo ich mir bislang immer mit einem "generischen" ASSIGN COMPONENT behelfen musste. Vorallem bei Verwendung von Standard-Strukturen sollte das deutlich schlankeren Code produzieren. Danke dafür.
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

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von DeathAndPain (Top Expert / 1961 / 261 / 415 ) »
Ich muss gestehen, dass ich bisher noch nie so richtig mit CASTING gearbeitet habe. Ich verstehe das Coding so einigermaßen, doch ein paar Fragen bleiben:
  • 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?
  • Wie gehe ich damit um, dass in solchen Strukturen wie den genannten Tabellen normalerweise noch andere Felder enthalten sind, die vor der Kette gleichartiger Feldgruppen kommen? Geht dann nicht das CASTING in die Hose?
Wenn es sich um eine SAP-DDIC-Tabelle handelt musst du halt das was ich hier im Code geschrieben habe analog im DDIC veranstalten.
Wie soll das gehen? Du arbeitest mit Unterstrukturen. Einerseits kann man keine strukturierten Datentypen in Datenbanktabellen verwenden,

Bild

andererseits braucht man das ja hauptsächlich für Standard-SAP-Tabellen, an denen man nicht herummodifizieren sollte.

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von a-dead-trousers (Top Expert / 4414 / 224 / 1186 ) »
Probier mal folgendes:
In der SE11 bei einer Tabelle (oder Struktur) als Feldname ".INCLUDE" und als Datentyp eine Struktur. :hallo:
Im Menü (Bearbeiten->Include->Einfügen) gibt es das Ganze als Muster inklusive den Suffixes und den Gruppennamen.
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

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von DeathAndPain (Top Expert / 1961 / 261 / 415 ) »
Dann macht er aber nichts anderes, als einfach die Felder aus der Struktur in die Tabelle zu übernehmen. Was er nicht macht, ist, eine Unterstruktur da reinzuschachteln, so wie Du es mit deinem TYPE beispiel2 machst. Dementsprechend kriegst Du die Struktur auch nur einmal in die Tabelle rein; RENAMING WITH ist nicht. Könnte man natürlich umgehen, indem man die numerierten Unterstrukturen alle einzeln von Hand im DDIC definiert. Aber dann kannste die includierten Strukturen gleich weglassen und die Felder alle der Reihe nach von Hand aufzählen (wie es bei den von uns genannten SAP-Standardtabellen ja auch der Fall ist).

Jetzt kann man probieren, ob das trotzdem funktioniert oder ob der Header der Unterstruktur auch ein Bytevolumen hat, durch das Dein ASSIGN INCREMENT dann scheitert. Das löst aber immer noch nicht das Problem, dass die Tabelle aus mehr besteht als nur den Feldern, die zu den Strukturgruppen gehören.

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von ewx (Top Expert / 4854 / 313 / 644 ) »
du kannst ein Include per .INCLU-ABC einfügen.
Der Zusatz ABC wird dann an die Feldnamen angehängt.
Aus MATNR wird dann MATNRABC.

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
DeathAndPain


Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von black_adept (Top Expert / 4103 / 128 / 945 ) »
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?
Beispiel ist genau so definiert wie in deinem 1. Post in diesem Thread. Es ist FELDGLEICH zum Feldsymbol, aber nicht Typgleich.

DeathAndPain hat geschrieben:andererseits braucht man das ja hauptsächlich für Standard-SAP-Tabellen, an denen man nicht herummodifizieren sollte.
Du arbeitest doch im HR - Schau dir mal die Struktur P1020 an.
DeathAndPain hat geschrieben:Wie soll das gehen? Du arbeitest mit Unterstrukturen. Einerseits kann man keine strukturierten Datentypen in Datenbanktabellen verwenden,
Genau deshalb habe ich die Anleitung geschrieben wie man eine "Analogstruktur" erstellt.

P.s: Nachtrag um 13:56: Besseres Beispiel aus dem HR: Struktur HRFPM_FIN_LIST - die ist mit Includes und Gruppennamen
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: DO... VARYING vs ASSIGN INCREMENT

Beitrag von DeathAndPain (Top Expert / 1961 / 261 / 415 ) »
Beispiel ist genau so definiert wie in deinem 1. Post in diesem Thread. Es ist FELDGLEICH zum Feldsymbol, aber nicht Typgleich.
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.

Dessen ungeachtet hat beispiel dann den Typ

Code: Alles auswählen.

BEGIN OF beispiel,
         wert1(5) type c,
         wert2(5) type c,
         wert3(5) type c,
       END OF beispiel.
und Dein Feldsymbol <ls_cast> den Typ

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.
Wie man das in irgendeiner Form aufeinander mappen können soll, ist mir komplett schleierhaft. Da passen weder die Feldnamen noch die Feldlängen zusammen?!
Besseres Beispiel aus dem HR: Struktur HRFPM_FIN_LIST - die ist mit Includes und Gruppennamen
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).

Machen wir es doch mal konkret: Kannst Du einen funktionierenden, vollständigen Beispielcode bieten, der in einer Schleife per ASSIGN INCREMENT aus einem HRP1020-Satz nacheinander die Bedarfe nebst Sprache liest? Es würde mich sehr interessieren, wie Du da mit CASTING arbeitest und dabei die ganzen Felder umgehst, mit denen die Tabelle anfängt. Die HRP1020 ist ein gutes Beispiel; bei vielen anderen Tabellen (z.B. PA0008, PA0041) ist es genau das gleiche.

Vergleichbare Themen

3
Antw.
838
Views
7 days increment by 1
von erzoo24 » 04.11.2021 15:21 • Verfasst in ABAP® für Anfänger
3
Antw.
5203
Views
Ersetzen von oboleten DO VARYING
von Barney » 25.10.2013 14:25 • Verfasst in ABAP® für Anfänger
13
Antw.
4615
Views
Assign
von robin1at » 10.04.2006 10:42 • Verfasst in ABAP® für Anfänger
0
Antw.
1680
Views
Dirty Assign
von allgrinder » 10.08.2015 11:14 • Verfasst in ABAP® für Anfänger
6
Antw.
2638
Views
ASSIGN-Probleme
von ralf.wenzel » 23.06.2008 09:41 • Verfasst in ABAP® Core

Über diesen Beitrag


Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Aktuelle Forenbeiträge

Nach MESSAGE TYPE E Felder entsperren
vor einer Woche von rob_abc gelöst 8 / 8598
ABAP - Mail so10 Text
vor einer Woche von retsch 6 / 2494
selection-screen comment mit icon
vor einer Woche von DeathAndPain 9 / 3801

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Nach MESSAGE TYPE E Felder entsperren
vor einer Woche von rob_abc gelöst 8 / 8598
ABAP - Mail so10 Text
vor einer Woche von retsch 6 / 2494
selection-screen comment mit icon
vor einer Woche von DeathAndPain 9 / 3801

Unbeantwortete Forenbeiträge

SD_PRINT_TERMS_OF_PAYMENT
vor einer Woche von Manfred K. 1 / 2903
BUSOBJEKT zu CMIS PHIO ermitteln
vor 4 Wochen von snooga87 1 / 4711