LOOP AT...ASSIGNING FIELDS-SYMBOL
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Beitrag
von PeterPaletti (Specialist / 348 / 32 /
97
)
»
Jetzt habe ich da diesen Code-Schnipsel
Ganz toll.
Wenig später im Code wird wieder eine Returntabelle ausgelesen.
Also:
Jetzt geht dasselbe FIELD-SYMBOL <return> nicht zweimal. Aber ich kann leider auch nicht sicher wissen, ob schon beim ersten Mal das LOOP durchlaufen und <return> zugewiesen wird.
Also zweimal ASSIGNING FIELD-SYMBOL(<return>) geht nicht, einmal ASSIGNING FIELD-SYMBOL(<return>) und einmal ASSIGNING <return> geht aber auch nicht, weil unsicher.
Also zur Sicherheit: einmal ASSIGNING FIELD-SYMBOL(<return>) und beim 2. Mal ASSIGNING FIELD-SYMBOL(<return2>).
Das ist doch doof. Gibt es da nicht eine schlauere Lösung?
Code: Alles auswählen.
LOOP AT returndata ASSIGNING FIELD-SYMBOL(<return>).
* mach was
ENDLOOP.
Wenig später im Code wird wieder eine Returntabelle ausgelesen.
Also:
Code: Alles auswählen.
LOOP AT returndata ASSIGNING FIELD-SYMBOL(<return>).
* mach was
ENDLOOP.
Also zweimal ASSIGNING FIELD-SYMBOL(<return>) geht nicht, einmal ASSIGNING FIELD-SYMBOL(<return>) und einmal ASSIGNING <return> geht aber auch nicht, weil unsicher.
Also zur Sicherheit: einmal ASSIGNING FIELD-SYMBOL(<return>) und beim 2. Mal ASSIGNING FIELD-SYMBOL(<return2>).
Das ist doch doof. Gibt es da nicht eine schlauere Lösung?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Glaube das wird zur Compilezeit generiert und steht dann zur Verfügung, ist genau so wie mit DATA, das kann auch ganz unten stehen und wird trotzdem auch oben erkannt. Man muss nur aufpassen wenn man das selbe FS für verschiedene Tabellen benutzt, besser ist FS nicht zu mischen sondern eindeutig zuzuweisen.
Der Loop weißt das Feld-Symbol immer neu zu egal ob es vorher schon einmal verwendet wurde oder nicht. Innerhalb des Loops ist es immer zugewiesen.Also zweimal ASSIGNING FIELD-SYMBOL(<return>) geht nicht, einmal ASSIGNING FIELD-SYMBOL(<return>) und einmal ASSIGNING <return> geht aber auch nicht, weil unsicher.
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
was ist daran "unsicher"?PeterPaletti hat geschrieben: ↑29.03.2022 12:25Also zweimal ASSIGNING FIELD-SYMBOL(<return>) geht nicht, einmal ASSIGNING FIELD-SYMBOL(<return>) und einmal ASSIGNING <return> geht aber auch nicht, weil unsicher.
SAP empfiehlt, separate Feld-symbole zu benutzen.PeterPaletti hat geschrieben: ↑29.03.2022 12:25Also zur Sicherheit: einmal ASSIGNING FIELD-SYMBOL(<return>) und beim 2. Mal ASSIGNING FIELD-SYMBOL(<return2>).
Das ist doch doof. Gibt es da nicht eine schlauere Lösung?
Willst du das Feldsymbol später - also außerhalb des LOOP - noch mal prüfen, musst eh prüfen, ob es zugewiesen ist:
Code: Alles auswählen.
IF <return> IS ASSIGNED...
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Ketzerisch gesprochen:
Wenn ich in einem Codemodul (Form-Routine, Methode) mehrmals den selben (oder einen ähnlichen) LOOP habe, dann habe ich bei der Modularisierung was falsch gemacht.
Oft hilft es schon die LOOPs in unterschieldiche Codemodule auszulagern und dann sieht man schon dass einer z.B. die Funktion "Suche nach Wildcard" und ein anderer die Funktion "Aktualisiere Zeilen mit Wert" abbildet. Wenn man die neuen Module dann auch noch sprechend bennennt, hat man mehr gewonnen als nur eine eindeutige Verwendung eines Inline-Feld-Symbols.
Wenn ich in einem Codemodul (Form-Routine, Methode) mehrmals den selben (oder einen ähnlichen) LOOP habe, dann habe ich bei der Modularisierung was falsch gemacht.
Oft hilft es schon die LOOPs in unterschieldiche Codemodule auszulagern und dann sieht man schon dass einer z.B. die Funktion "Suche nach Wildcard" und ein anderer die Funktion "Aktualisiere Zeilen mit Wert" abbildet. Wenn man die neuen Module dann auch noch sprechend bennennt, hat man mehr gewonnen als nur eine eindeutige Verwendung eines Inline-Feld-Symbols.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ewx
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 PeterPaletti (Specialist / 348 / 32 /
97
)
»
Da bin ich etwas anderer Ansicht.a-dead-trousers hat geschrieben: ↑29.03.2022 13:09Ketzerisch gesprochen:
Wenn ich in einem Codemodul (Form-Routine, Methode) mehrmals den selben (oder einen ähnlichen) LOOP habe, dann habe ich bei der Modularisierung was falsch gemacht.
Oft hilft es schon die LOOPs in unterschieldiche Codemodule auszulagern und dann sieht man schon dass einer z.B. die Funktion "Suche nach Wildcard" und ein anderer die Funktion "Aktualisiere Zeilen mit Wert" abbildet. Wenn man die neuen Module dann auch noch sprechend bennennt, hat man mehr gewonnen als nur eine eindeutige Verwendung eines Inline-Feld-Symbols.
Wenn ich nacheinander zwei Funktionsbausteine aufrufe, die mir beide Rückgabewerte vom Typ BAPIRET2 liefern, warum soll ich dann für die Rückgabewerte nicht dieselbe Tabelle verwenden?
Gut, ich könnte für jeden Funktionsbausteinsaufruf jeweils eine Formroutine/Modul,/Methode bauen, und in der Formroutine jeweils den Return abfragen. Wirkt aber unter Umständen auch etwas albern.
Beitrag
von PeterPaletti (Specialist / 348 / 32 /
97
)
»
Aha, SAP ist also für <return1> und <return2>. Gut zu wissen, sieht aber in meinen Augen trotzdem blöd aus.ewx hat geschrieben: ↑29.03.2022 13:06was ist daran "unsicher"?PeterPaletti hat geschrieben: ↑29.03.2022 12:25Also zweimal ASSIGNING FIELD-SYMBOL(<return>) geht nicht, einmal ASSIGNING FIELD-SYMBOL(<return>) und einmal ASSIGNING <return> geht aber auch nicht, weil unsicher.
SAP empfiehlt, separate Feld-symbole zu benutzen.PeterPaletti hat geschrieben: ↑29.03.2022 12:25Also zur Sicherheit: einmal ASSIGNING FIELD-SYMBOL(<return>) und beim 2. Mal ASSIGNING FIELD-SYMBOL(<return2>).
Das ist doch doof. Gibt es da nicht eine schlauere Lösung?
Willst du das Feldsymbol später - also außerhalb des LOOP - noch mal prüfen, musst eh prüfen, ob es zugewiesen ist:Code: Alles auswählen.
IF <return> IS ASSIGNED...
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
So hab ich das jetzt nicht gemeint. Vielmehr würde ich die Verarbeitung von BAPIRET2 in eine eigene Form-Routine/Methode auslagern. In diesem Fall wird vermutlich geprüft ob ein Fehler vorliegt oder ähnliches und das ist doch für die beiden besagten Funktionsbausteinaufrufe im Grund dieselbe Logik.PeterPaletti hat geschrieben: ↑29.03.2022 13:51Wenn ich nacheinander zwei Funktionsbausteine aufrufe, die mir beide Rückgabewerte vom Typ BAPIRET2 liefern, warum soll ich dann für die Rückgabewerte nicht dieselbe Tabelle verwenden?
Somit braucht es nur einen Loop, ein Feldsymbol aber zwei PERFORM/CALL METHOD.
*Bam* Modularisierung 😇
Code: Alles auswählen.
CALL FUNCTION ... TABLES returntab = lt_return.
PERFORM check_error USING lt_return CHANGING ld_error.
IF ld_error NE abap_true.
CALL FUNCTION ... TABLES returntab = lt_return.
PERFORM check_error USING lt_return CHANGING ld_error.
ENDIF.
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 black_adept (Top Expert / 4093 / 128 /
940
)
»
Moin Peter,PeterPaletti hat geschrieben: ↑29.03.2022 12:25Also zur Sicherheit: einmal ASSIGNING FIELD-SYMBOL(<return>) und beim 2. Mal ASSIGNING FIELD-SYMBOL(<return2>).
Das ist doch doof. Gibt es da nicht eine schlauere Lösung?
ich glaube du hast noch nicht vollständig das Konzept der impliziten Variablendefinition verstanden.
Mit LOOP AT ... ASSIGNING FIELD-SYMBOL(<return>) definierst du ein Feldsymbol. Dieses ist dem Sichtbarkeitsbereich zugeordnet, in dem du dich gerade befindest.
Analog könntest du in der Zeile davor ein FIELD-SYMBOLS: <return> like line of itab. schreiben.
Somit ist das 2. LOOP AT ... ASSIGNING <return> nicht unsicher. Warum auch? ASSIGNING <fs> weist dem Feldsymbol die Zeile der itab zu. Problematisch wäre nur ( und ich fürchte, dass meintest du ) wenn du stattdess LOOP AT ... INTO <return> machen würdest, weil dieses evtl. nicht assigned ist.
P.S. Auch wenn man jeden schlagen sollte, der es probiert. Eine Variable, die mittels LOOP AT ... INTO DATA(var) definiert wird, ist zwar erst nach der Deklaration via Coding ansprechbar, aber sie existiert auch schon vorher - in der gesamten Modularisierungseinheit. Einfach mal einen Breakpoint vor den LOOP platzieren und im Debugger die in der nächsten Zeile definierte Variable anschauen. Glücklicherweise geht so ein Schmarrn nicht mit Feldsymbolen.
Seite 1 von 1
Vergleichbare Themen
6
Antw.
Antw.
800
Views
Views
15
Antw.
Antw.
4717
Views
Views
2
Antw.
Antw.
13130
Views
Views
LOOP AT INTO und ASSIGNING (gelöst)
von beterman » 17.10.2011 15:56 • Verfasst in ABAP® für Anfänger
von beterman » 17.10.2011 15:56 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
1479
Views
Views
Loop Loop & Loop - wie am besten eine Verschachtelung vermeiden?
von Sonne1234 » 05.02.2020 16:29 • Verfasst in ABAP® für Anfänger
von Sonne1234 » 05.02.2020 16:29 • Verfasst in ABAP® für Anfänger
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.