LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
33 Beiträge • Vorherige Seite 2 von 3 (current) Nächste
33 Beiträge Vorherige Seite 2 von 3 (current) Nächste

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von a-dead-trousers (Top Expert / 3659 / 131 / 953 ) »
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.
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.07
Basis: 7.40


Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von ralf.wenzel (Top Expert / 3570 / 167 / 244 ) »
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.
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 klingt alles ein bisschen nach einer Multiton-Implementierung.
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.
Das verstehe ich schon wieder nicht - die Methodenparameter haben doch mit dem READ erstmal nix zu tun.


Ralf

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von a-dead-trousers (Top Expert / 3659 / 131 / 953 ) »
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 klingt alles ein bisschen nach einer Multiton-Implementierung.
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:Das verstehe ich schon wieder nicht - die Methodenparameter haben doch mit dem READ erstmal nix zu tun.
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.
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.07
Basis: 7.40

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von ralf.wenzel (Top Expert / 3570 / 167 / 244 ) »
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

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von a-dead-trousers (Top Expert / 3659 / 131 / 953 ) »
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).
Geht natürlich auch. Ich will halt die Struktur der Datentabelle möglichst nahe an der Datenbank haben.
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?
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.
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.07
Basis: 7.40

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von ralf.wenzel (Top Expert / 3570 / 167 / 244 ) »
a-dead-trousers hat geschrieben:(SORT funktioniert auch mit TABLE_LINE->ATTRIBUTE und danach READ TABLE mit BINARY SEARCH)
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.....


Gruß

Ralf

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von mazu (ForumUser / 53 / 0 / 0 ) »
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.

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von nickname8 (Specialist / 129 / 17 / 19 ) »
Create Data sflight_ref.
"Hier Schlüssel füllen
...
Insert sflight_ref->* into table sflight_tab reference into sflight_ref.
sflight_ref->price = sflight_ref->price * '0.9'.

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von a-dead-trousers (Top Expert / 3659 / 131 / 953 ) »
APPEND INITIAL LINE TO ... REFERENCE INTO ...
:P

EDIT:
nickname8 war um einen Hauch schneller. :cry:
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.07
Basis: 7.40

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von nickname8 (Specialist / 129 / 17 / 19 ) »
a-dead-trousers hat geschrieben:APPEND INITIAL LINE TO ... REFERENCE INTO ...
:P
Append an eine sortierte Tabelle? :?

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von a-dead-trousers (Top Expert / 3659 / 131 / 953 ) »
nickname8 hat geschrieben:Append an eine sortierte Tabelle? :?
Wenn Sie leer ist geht das. :P
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.
EDIT:
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.07
Basis: 7.40

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von nickname8 (Specialist / 129 / 17 / 19 ) »
Kein Problem! :)
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.
.
Das VALUE# macht das CREATE DATA implizit?

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von a-dead-trousers (Top Expert / 3659 / 131 / 953 ) »
nickname8 hat geschrieben:Das VALUE# macht das CREATE DATA implizit?
Jepp, aber leider nur in der neuen Syntax.
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.07
Basis: 7.40

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von mazu (ForumUser / 53 / 0 / 0 ) »
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.

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Beitrag von nickname8 (Specialist / 129 / 17 / 19 ) »
mazu hat geschrieben: SFLIGHT_REF->MANDT = SY-MANDT.
Nur, wenn du auch in deiner sortierten Tabelle mandt als Schlüssel deklariert hast.
mazu hat geschrieben:Ab welcher Version gilt diese Syntax?
7.40


Aktuelle Forenbeiträge

SmartForms show table...
vor 2 Tagen von Lucyalison 2 / 2249
Wie groß ist mein DynPro?
vor 2 Tagen von JanR gelöst 3 / 1126

Vergleichbare Themen

Loop zu einem Read Table machen
von cschmoel » 03.09.2012 09:01
LOOP über führende interne Tabelle + READ TABLE und MODIFY
von HawkDT » 23.03.2017 13:02
read table
von kostonstyle » 27.03.2008 15:38
Read Table mit MAX Datum und Zeit
von autohandel7 » 23.08.2018 10:54
READ TABLE dynamisch aufrufen
von RiffRaff » 27.12.2004 12:04