LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING
Beitrag
von a-dead-trousers (Top Expert / 4451 / 227 /
1197
)
»
Ich verwende hier eher den READ TABLE ... REFERENCE INTO:
Die GET_DATASET Methode schaut nach ob es schon ein Objekt mit der gewünschten Datensatz ID gibt. Wenn nicht, wird der Datensatz etweder aus der internen Tabelle mit READ TABLE ... REFERENCE INTO gelesen oder per INSERT INTO ... REFERENCE INTO hinzugefügt. Dann wird eine Instanz der Datensatzklasse erzeugt und dieser die Referenz des Datensatzes mitgegeben. Nach "außen" sieht es so aus als ob jeder Datensatz für sich alleine steht, aber im Endeffekt weis die zentrale Datenklasse über alles Bescheid und kann für übergreifende Änderungen (CLONE, COMMIT, ROLLBACK usw.) herangezogen werden ohne erst alle beteiligten Objekte abfragen zu müssen. Im Endeffekt handelt es sich um eine Abkürzung ohne den OO Grundgedanken zu verletzen. Eine Anwendung mit LOOP AT ... REFERENCE INTO in diesem Kontext wäre eine Methode GET_DATASETS die gleich mehrere Objekte z.B. anhand eines Filters bzw. einer Rangetabelle erzeugt.
Was ich früher in meinen Klassen oft hatte, waren mehrere READ TABLE ... ASSIGNING Anweisungen hintereinander die oft dasselbe, nur halt mit unterschiedlichen Parametern, machten. Weil aber Feld-Symbole nur programmlokal funktionieren, erschien es mir nicht sinnvoll das in einer Methode zu kapseln. So wurde oft ein ziemlich unübersichtlicher Haufen von READ TABLE daraus.
Eine weitere Anwendung die mir für das REFERENCE INTO einfiele, wäre ein Datensatz Iterator.
Die GET_DATASET Methode schaut nach ob es schon ein Objekt mit der gewünschten Datensatz ID gibt. Wenn nicht, wird der Datensatz etweder aus der internen Tabelle mit READ TABLE ... REFERENCE INTO gelesen oder per INSERT INTO ... REFERENCE INTO hinzugefügt. Dann wird eine Instanz der Datensatzklasse erzeugt und dieser die Referenz des Datensatzes mitgegeben. Nach "außen" sieht es so aus als ob jeder Datensatz für sich alleine steht, aber im Endeffekt weis die zentrale Datenklasse über alles Bescheid und kann für übergreifende Änderungen (CLONE, COMMIT, ROLLBACK usw.) herangezogen werden ohne erst alle beteiligten Objekte abfragen zu müssen. Im Endeffekt handelt es sich um eine Abkürzung ohne den OO Grundgedanken zu verletzen. Eine Anwendung mit LOOP AT ... REFERENCE INTO in diesem Kontext wäre eine Methode GET_DATASETS die gleich mehrere Objekte z.B. anhand eines Filters bzw. einer Rangetabelle erzeugt.
Was ich früher in meinen Klassen oft hatte, waren mehrere READ TABLE ... ASSIGNING Anweisungen hintereinander die oft dasselbe, nur halt mit unterschiedlichen Parametern, machten. Weil aber Feld-Symbole nur programmlokal funktionieren, erschien es mir nicht sinnvoll das in einer Methode zu kapseln. So wurde oft ein ziemlich unübersichtlicher Haufen von READ TABLE daraus.
Eine weitere Anwendung die mir für das REFERENCE INTO einfiele, wäre ein Datensatz Iterator.
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
Beitrag
von ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Du hast also eine Tabelle mit Objekten in einer der Klassen. Zeilentyp = Referenztyp? Das würde bedeuten, du hast eine Referenz auf eine Referenz....a-dead-trousers hat geschrieben:Ich verwende hier eher den READ TABLE ... REFERENCE INTO:
Die GET_DATASET Methode schaut nach ob es schon ein Objekt mit der gewünschten Datensatz ID gibt.
Die Datensatz-ID ist ein Attribut aller Objekte und hat immer denselben Datentyp? Warum dann nicht LOOP AT....ASSIGNING...ID = ...?
Sorry, ich will es nur verstehen
Das klingt alles ein bisschen nach einer Multiton-Implementierung.Das verstehe ich schon wieder nicht - die Methodenparameter haben doch mit dem READ erstmal nix zu tun.a-dead-trousers hat geschrieben:Was ich früher in meinen Klassen oft hatte, waren mehrere READ TABLE ... ASSIGNING Anweisungen hintereinander die oft dasselbe, nur halt mit unterschiedlichen Parametern, machten. Weil aber Feld-Symbole nur programmlokal funktionieren, erschien es mir nicht sinnvoll das in einer Methode zu kapseln. So wurde oft ein ziemlich unübersichtlicher Haufen von READ TABLE daraus.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4451 / 227 /
1197
)
»
Im Endeffekt habe ich ZWEI Tabellen in der Datenklasse. Eine davon ist struktuiert und ist für die zentrale Datenhaltung zuständig. Die andere hällt die Objektreferenzen der erzeugten Datensatzklassen damit je Datensatz auch nur wirklich eine Klasse instanziert wird. Die Datensatzklassen halten intern nur eine Referenz auf eine Zeile der ersten Tabelle und können somit ihre Änderungen direkt in diese hineinschreiben.ralf.wenzel hat geschrieben:Du hast also eine Tabelle mit Objekten in einer der Klassen. Zeilentyp = Referenztyp? Das würde bedeuten, du hast eine Referenz auf eine Referenz....
Die Datensatz-ID ist ein Attribut aller Objekte und hat immer denselben Datentyp? Warum dann nicht LOOP AT....ASSIGNING...ID = ...?
Sorry, ich will es nur verstehen
Das ist ein anderes Beispiel um zu verdeutlichen, dass man mit Referenzen auch "Alt"-Code verbessern kann indem man "komplizierte" und wiederkehrende READ TABLEs mit mehreren Parametern in eine Methode auslagern kann OHNE auf die direkte Änderbarkeit der Inhalte verzichten zu müssen. Sonst bräucht man ja wie zur ABAP-Steinzeit mit einem Workarea nach den Änderungen im Datensatz ein MODIFY um die Tabellenzeile zu ändern.ralf.wenzel hat geschrieben:Das verstehe ich schon wieder nicht - die Methodenparameter haben doch mit dem READ erstmal nix zu tun.
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 ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
a-dead-trousers hat geschrieben:[Im Endeffekt habe ich ZWEI Tabellen in der Datenklasse. Eine davon ist struktuiert und ist für die zentrale Datenhaltung zuständig. Die andere hällt die Objektreferenzen der erzeugten Datensatzklassen damit je Datensatz auch nur wirklich eine Klasse instanziert wird. Die Datensatzklassen halten intern nur eine Referenz auf eine Zeile der ersten Tabelle und können somit ihre Änderungen direkt in diese hineinschreiben.
Warum fasst du die nicht in einer Tabelle zusammen? Ich mache solche Tabellen in der Regel so, dass ich ein paar Spalten habe für wichtige Attribute und eine letzte für die Objektreferenz (damit ich keinen READ direkt auf Tabellenattribute machen muss, der einigen Restriktionen unterliegt).
Du suchst und findest in der Datentabelle ein Objekt mit einem bestimmten Attributsinhalt - wie schließt du auf die Position in der Objekttabelle?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4451 / 227 /
1197
)
»
Geht natürlich auch. Ich will halt die Struktur der Datentabelle möglichst nahe an der Datenbank haben.ralf.wenzel hat geschrieben:Warum fasst du die nicht in einer Tabelle zusammen? Ich mache solche Tabellen in der Regel so, dass ich ein paar Spalten habe für wichtige Attribute und eine letzte für die Objektreferenz (damit ich keinen READ direkt auf Tabellenattribute machen muss, der einigen Restriktionen unterliegt).
Die Positionen sind mir eigentlich egal. Ich durchsuche zuerst die Objektabelle nach einer bereits vorhandenen Instanz mit der ID und nur wenn nichts gefunden wurde wird die Datentabelle durchsucht.ralf.wenzel hat geschrieben:Du suchst und findest in der Datentabelle ein Objekt mit einem bestimmten Attributsinhalt - wie schließt du auf die Position in der Objekttabelle?
Da beide nach der ID sortiert sind, geht das recht zügig.
(SORT funktioniert auch mit TABLE_LINE->ATTRIBUTE und danach READ TABLE mit BINARY SEARCH)
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 ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Richtig, aber man kann keine sortierte Tabelle anlegen mit Key = Attribut. DAS ist der Grund, warum ich die wichtigsten Attribute nach denen ich lesen könnte, rausziehe in separate Spalten.....a-dead-trousers hat geschrieben:(SORT funktioniert auch mit TABLE_LINE->ATTRIBUTE und danach READ TABLE mit BINARY SEARCH)
Gruß
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
in dem Zusammenhang hab ich mal ne Frage: hab das mal mit REFERENCE INTO ausprobiert. ist ja ganz hübsch.
Meine Frage seht ihr unten im Coding .
DATA sflight_tab TYPE SORTED TABLE OF sflight
WITH UNIQUE KEY carrid connid fldate.
DATA sflight_ref TYPE REF TO sflight.
SELECT *
FROM sflight
INTO TABLE sflight_tab
WHERE carrid = p_carrid AND
connid = p_connid.
IF sy-subrc = 0.
READ TABLE sflight_tab
WITH TABLE KEY carrid = p_carrid
connid = p_connid
fldate = p_fldate
REFERENCE INTO sflight_ref.
IF sy-subrc = 0.
sflight_ref->price = sflight_ref->price * '0.9'.
ELSE.
Und hier die Preisfrage: was und wie referenziert man an diesem Punkt: es gibt keine Zeile in der Tabelle; die will ich jetzt manuell anhängen.
sflight_ref hat die Objektreferenz NULL an diesem Punkt.
Früher hätte man einfach die Struktur/like line of definiert, abgefüllt, und per Append drangehängt. Brauch ich jetzt noch eine Zeilenreferenz?
Läuft das mit GET REFERENCE?
ENDIF.
in dem Zusammenhang hab ich mal ne Frage: hab das mal mit REFERENCE INTO ausprobiert. ist ja ganz hübsch.
Meine Frage seht ihr unten im Coding .
DATA sflight_tab TYPE SORTED TABLE OF sflight
WITH UNIQUE KEY carrid connid fldate.
DATA sflight_ref TYPE REF TO sflight.
SELECT *
FROM sflight
INTO TABLE sflight_tab
WHERE carrid = p_carrid AND
connid = p_connid.
IF sy-subrc = 0.
READ TABLE sflight_tab
WITH TABLE KEY carrid = p_carrid
connid = p_connid
fldate = p_fldate
REFERENCE INTO sflight_ref.
IF sy-subrc = 0.
sflight_ref->price = sflight_ref->price * '0.9'.
ELSE.
Und hier die Preisfrage: was und wie referenziert man an diesem Punkt: es gibt keine Zeile in der Tabelle; die will ich jetzt manuell anhängen.
sflight_ref hat die Objektreferenz NULL an diesem Punkt.
Früher hätte man einfach die Struktur/like line of definiert, abgefüllt, und per Append drangehängt. Brauch ich jetzt noch eine Zeilenreferenz?
Läuft das mit GET REFERENCE?
ENDIF.
Beitrag
von a-dead-trousers (Top Expert / 4451 / 227 /
1197
)
»
APPEND INITIAL LINE TO ... REFERENCE INTO ...
EDIT:
nickname8 war um einen Hauch schneller.
EDIT:
nickname8 war um einen Hauch schneller.
Zuletzt geändert von a-dead-trousers am 12.11.2018 19:30, 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
Beitrag
von a-dead-trousers (Top Expert / 4451 / 227 /
1197
)
»
Wenn Sie leer ist geht das.nickname8 hat geschrieben:Append an eine sortierte Tabelle?
Aber auch mit einem INSERT kann man da ganz schön auf die Schnauze fallen, wenn man den Primary-Key erst "verspätet" ausfüllt.
Besser:
Code: Alles auswählen.
INSERT VALUE #( carrid = p_carrid connid = p_connid fldate = p_fldate ) INTO TABLE sflight_tab REFERENCE INTO sflight_ref.Ups. Hab deinen Kommentar "Hier Schlüssel füllen überlesen. Nehm alles wieder zurück.
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
Kein Problem! 
Das VALUE# macht das CREATE DATA implizit?a-dead-trousers hat geschrieben: Besser:.Code: Alles auswählen.
INSERT VALUE #( carrid = p_carrid connid = p_connid fldate = p_fldate ) INTO TABLE sflight_tab REFERENCE INTO sflight_ref.
Beitrag
von a-dead-trousers (Top Expert / 4451 / 227 /
1197
)
»
Jepp, aber leider nur in der neuen Syntax.nickname8 hat geschrieben:Das VALUE# macht das CREATE DATA implizit?
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
Hallo Ihr Beiden
also so geht's...
ELSE.
CREATE DATA SFLIGHT_REF.
*"Hier Schlüssel füllen
SFLIGHT_REF->MANDT = SY-MANDT.
SFLIGHT_REF->CARRID = 'LH'.
SFLIGHT_REF->CONNID = '017'.
SFLIGHT_REF->FLDATE = '20180101'.
INSERT SFLIGHT_REF->* INTO TABLE SFLIGHT_TAB REFERENCE INTO SFLIGHT_REF.
Euer 2t Variante geht bei mir nicht:
INSERT VALUE # ( carrid = p_carrid connid = p_connid fldate = p_fldate ) INTO TABLE sflight_tab REFERENCE INTO sflight_ref.
da bekomme ich folgende Fehlermeldung:
Statt "# ( CARRID = P_CARRID CONNID =" wurde "CLIENT SPECIFIED
CONNECTION ...", "CLIENT SPECIFIED FROM", "CONNECTION ... FROM" oder
"FROM" erwartet.
Ab welcher Version gilt diese Syntax?
Zusatz: meiner Meinung erreicht man dasselbe, wenn man statt CREATE DATA folgendes schreibt:
GET REFERENCE OF SFLIGHT INTO SFLIGHT_REF.
Vorher muss man die SFLIGHT z.b. per Tables Deklaration bekanntmachen:
TABLES: SFLIGHT.
also so geht's...
ELSE.
CREATE DATA SFLIGHT_REF.
*"Hier Schlüssel füllen
SFLIGHT_REF->MANDT = SY-MANDT.
SFLIGHT_REF->CARRID = 'LH'.
SFLIGHT_REF->CONNID = '017'.
SFLIGHT_REF->FLDATE = '20180101'.
INSERT SFLIGHT_REF->* INTO TABLE SFLIGHT_TAB REFERENCE INTO SFLIGHT_REF.
Euer 2t Variante geht bei mir nicht:
INSERT VALUE # ( carrid = p_carrid connid = p_connid fldate = p_fldate ) INTO TABLE sflight_tab REFERENCE INTO sflight_ref.
da bekomme ich folgende Fehlermeldung:
Statt "# ( CARRID = P_CARRID CONNID =" wurde "CLIENT SPECIFIED
CONNECTION ...", "CLIENT SPECIFIED FROM", "CONNECTION ... FROM" oder
"FROM" erwartet.
Ab welcher Version gilt diese Syntax?
Zusatz: meiner Meinung erreicht man dasselbe, wenn man statt CREATE DATA folgendes schreibt:
GET REFERENCE OF SFLIGHT INTO SFLIGHT_REF.
Vorher muss man die SFLIGHT z.b. per Tables Deklaration bekanntmachen:
TABLES: SFLIGHT.
Nur, wenn du auch in deiner sortierten Tabelle mandt als Schlüssel deklariert hast.mazu hat geschrieben: SFLIGHT_REF->MANDT = SY-MANDT.
7.40mazu hat geschrieben:Ab welcher Version gilt diese Syntax?
Vergleichbare Themen
4
Antw.
Antw.
8961
Views
Views
3
Antw.
Antw.
4076
Views
Views
LOOP über führende interne Tabelle + READ TABLE und MODIFY
von HawkDT » 23.03.2017 13:02 • Verfasst in ABAP® für Anfänger
von HawkDT » 23.03.2017 13:02 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
19713
Views
Views
8
Antw.
Antw.
10203
Views
Views
Read Table mit MAX Datum und Zeit
von autohandel7 » 23.08.2018 10:54 • Verfasst in ABAP® für Anfänger
von autohandel7 » 23.08.2018 10:54 • 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
Vertriebsstücklisten per IDOC ohne Unterpositionen in der Auftragsbestätigung übertragen
vor 2 Stunden von Herbert_zarg 2 / 2500
vor 2 Stunden von Herbert_zarg 2 / 2500
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Vertriebsstücklisten per IDOC ohne Unterpositionen in der Auftragsbestätigung übertragen
vor 2 Stunden von Herbert_zarg 2 / 2500
vor 2 Stunden von Herbert_zarg 2 / 2500