SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen Thema ist als GELÖST markiert

Getting started ... Alles für einen gelungenen Start.
18 Beiträge • Seite 1 von 2 (current) Nächste
18 Beiträge Seite 1 von 2 (current) Nächste

SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von tm987456 (ForumUser / 60 / 36 / 12 ) » 20.10.2020 13:08
Hallo zusammen

Gegeben ist eine Tabelle mit BP und Adressnummer

Code: Alles auswählen.

TYPES:
    BEGIN OF ty_address_key,
      business_partner_id TYPE bu_partner,
      address_id          TYPE ad_addrnum,
    END OF ty_address_key,
    tty_address_ids          TYPE SORTED TABLE OF ty_address_key WITH UNIQUE KEY business_partner_id.

DATA:
    address_ids TYPE tty_address_ids.
Gefüllt ist die Tabelle mit der BP-ID und der zugehörigen Adressid der Standardadresse. Nun möchte ich alle zugehörigen E-Mailadressen aus ADR6 lesen und die Emailadresse + Adress-ID und BP-Nummer in einer neuen Tabelle speichern.

Gelöst habe ich das wie folgt:

Code: Alles auswählen.

    SELECT addrnumber, smtp_addr FROM adr6
      FOR ALL ENTRIES IN @address_ids
      WHERE addrnumber = @address_ids-address_id
      INTO @DATA(email_address).

      email_addresses = VALUE #( BASE email_addresses
        (
          address_id = email_address-addrnumber
          business_partner_id = address_ids[ address_id = email_address-addrnumber ]-business_partner_id
          email_address = email_address-smtp_addr
        )
      ).
    ENDSELECT.
Allerdings ist das natürlich extrem langsam. Der Loop und die Suche nach der BP-Nummer über die Adressnummer dauern ewig.

Warum kann ich nicht sowas schreiben:

Code: Alles auswählen.

    SELECT @std_address_ids-business_partner_id, addrnumber, smtp_addr FROM adr6
      FOR ALL ENTRIES IN @std_address_ids
      WHERE addrnumber = @std_address_ids-address_id
      INTO TABLE @DATA(email_address).
So würde es gehen, aber ein eigentlich unnötiger Join.

Code: Alles auswählen.

    SELECT a~partner, b~addrnumber, b~smtp_addr FROM but021_fs AS a
      JOIN adr6 AS b ON b~addrnumber = a~addrnumber
      FOR ALL ENTRIES IN @std_address_ids
      WHERE a~partner = @std_address_ids-business_partner_id
        AND b~addrnumber = @std_address_ids-address_id
      INTO TABLE @DATA(email_address2).

Was übersehe ich? Das muss doch leichter/schneller zu lösen sein.
Zuletzt geändert von tm987456 am 21.10.2020 08:39, insgesamt 1-mal geändert.


Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von a-dead-trousers (Top Expert / 3563 / 120 / 928 ) » 20.10.2020 15:01
Probiers mal so:

Code: Alles auswählen.

SELECT addrnumber, smtp_addr FROM adr6
      FOR ALL ENTRIES IN @std_address_ids
      WHERE addrnumber = @std_address_ids-address_id
      INTO TABLE @DATA(email_address).
Da du die 'addrnumber' und die 'address_id' sowieso gleich setzt, brauchst du das Ganze doch nicht zweimal im SELECT.

EDIT:
Okay... du willst auch den BP im SELECT haben... Die zweite Query war dann aber mit dem falschen Feld.

Dein zweiter Ansatz schaut schon ziemlich richtig aus. Zur Optimierung würde ich nun nur noch das SELECT, das dir die Tabelle für den FOR ALL ENTRIES befüllt, in die Query miteinbauen, dann läuft das schon sehr performant ab.
(FOR ALL ENTRIES ist bei großen Datenmengen eine nicht zu unterschätzende Performance Krüke)
Zur Optimierung würde ich den JOIN in einen DB-View oder CDS-View auslagern und dann sollte das auch im Programmcode "schön" ausschauen (ohne die ganzen @, ~ usw.)

Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
tm987456

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: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von tm987456 (ForumUser / 60 / 36 / 12 ) » 21.10.2020 09:06
Hallo adt

du hast recht. im zweiten Query muss das erste Feld natürlich business_partner_id heissen. Habe ich korrigiert.

Das heisst, du würdest, obwohl du bereits alle Business Partner IDs und zugehörigen Adressen IDs in einer internen Tabelle hast, alles mit zwei Joins neu lesen, um den FOR ALL ENTRIES zu vermeiden?

Ob das schön aussieht oder nicht, ist mir eigentlich egal.

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von a-dead-trousers (Top Expert / 3563 / 120 / 928 ) » 21.10.2020 17:45
tm987456 hat geschrieben:
21.10.2020 09:06
Das heisst, du würdest, obwohl du bereits alle Business Partner IDs und zugehörigen Adressen IDs in einer internen Tabelle hast, alles mit zwei Joins neu lesen, um den FOR ALL ENTRIES zu vermeiden?
Jein. Ich würde die Query die die Business Partner IDs und zugehörigen Adressen IDs ermittelt mit der zweiten Query verknüpfen WENN ES SINN macht.
Da ich aus deinem bisherigen Coding nichts Gegenteiliges herausgelesen hab, würde es für mich Sinn machen. ;)
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: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von black_adept (Top Expert / 3446 / 68 / 673 ) » 22.10.2020 11:05
tm987456 hat geschrieben:
20.10.2020 13:08
Warum kann ich nicht sowas schreiben:

Code: Alles auswählen.

    SELECT @std_address_ids-business_partner_id, addrnumber, smtp_addr FROM adr6
      FOR ALL ENTRIES IN @std_address_ids
      WHERE addrnumber = @std_address_ids-address_id
      INTO TABLE @DATA(email_address).
Was übersehe ich? Das muss doch leichter/schneller zu lösen sein.
Das Problem ist, dass ein "FOR ALL ENTRIES" die Möglichkeiten des SELECTs einfach arg einschränkt. Allerdings hat uns SAP in modernen Releases ( ab. 7.52 ) eine Alternative gegeben die man manchmal verwenden kann: Man darf neuerdings EINE interne Tabelle in einer JOIN-Bedingungn verwenden anstatt einer DB-Tabelle. -->Doku<--
Und das entspricht manchmal einer "FOR ALL ENTRIES"-Selektion.

Beispiel wo ich Daten aus einer internen Tabelle und einer DB-Tabelle in eine Zieltabelle zusammenwerfe - das sollte deinem Beispiel entsprechen ist aber so für alle nachvollziehbar.

Code: Alles auswählen.

REPORT.

SELECT land1, waers, spras
  FROM t005
  INTO TABLE @DATA(lt_test) UP TO 5 ROWS.

SELECT itab~land1, itab~waers,
       t005t~landx
  FROM @lt_test AS itab JOIN t005t ON t005t~land1 = itab~land1
  WHERE t005t~spras = @sy-langu
  INTO TABLE @DATA(lt_mixed).
BREAK-POINT.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 5):
qyurryusewxa-dead-trouserstm987456Radinator

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von tm987456 (ForumUser / 60 / 36 / 12 ) » 22.10.2020 12:36
Ja perfekt. Genau sowas habe ich gesucht. Danke!

Code: Alles auswählen.

    SELECT ids~business_partner_id, ids~address_id, emails~smtp_addr FROM adr6 AS emails
      INNER JOIN @std_address_ids AS ids ON ids~address_id = emails~addrnumber
      INTO TABLE @email_addresses.
Macht es Sinn prinzipiell FOR ALL ENTIRES Situationen durch den Join zu ersetzten? Performance sollte ja auch besser sein.

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von qyurryus (ForumUser / 56 / 45 / 17 ) » 22.10.2020 15:53
Das gute am Join ist vor allem dass es deutlich robuster ist - bei Benutzung von FOR ALL ENTRIES muss man in der Regel erst auf Leerheit prüfen, da man sonst die gesamte Tabelle selektiert...

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von DeathAndPain (Top Expert / 1466 / 162 / 331 ) » 26.10.2020 13:29
Macht es Sinn prinzipiell FOR ALL ENTIRES Situationen durch den Join zu ersetzten? Performance sollte ja auch besser sein.
Das kann ich mir, ehrlich gesagt, nicht vorstellen. Was ABAP da macht, kann ja kein echter JOIN auf Datenbankebene sein, denn die Datenbank kennt die interne Tabelle nicht. Also kann ABAP ja nichts anderes machen, als die Werte aus der internen Tabelle einzeln an die Datenbank zu übertragen, vermutlich als WHERE fraglicher_wert IN (wert1,wert2,wert3,...). Genau das macht aber auch der FOR ALL ENTRIES IN. Von daher halte ich es performancetechnisch für ein Nullsummenspiel. Müsste man mal austesten, was da schneller ist.

Die Diskussion mit adt habe ich nicht wirklich verstanden, weil da zu abstrakt (also ohne konkreten Code) argumentiert wurde. Ich verstehe aber auch nicht, wie in Deinem ursprünglichen Posting
Gelöst habe ich das wie folgt:

Code: Alles auswählen.

    SELECT addrnumber, smtp_addr FROM adr6
      FOR ALL ENTRIES IN @address_ids
      WHERE addrnumber = @address_ids-address_id
      INTO @DATA(email_address).

      email_addresses = VALUE #( BASE email_addresses
        (
          address_id = email_address-addrnumber
          business_partner_id = address_ids[ address_id = email_address-addrnumber ]-business_partner_id
          email_address = email_address-smtp_addr
        )
      ).
    ENDSELECT.
äquivalent sein soll zu
So würde es gehen, aber ein eigentlich unnötiger Join.

Code: Alles auswählen.

    SELECT a~partner, b~addrnumber, b~smtp_addr FROM but021_fs AS a
      JOIN adr6 AS b ON b~addrnumber = a~addrnumber
      FOR ALL ENTRIES IN @std_address_ids
      WHERE a~partner = @std_address_ids-business_partner_id
        AND b~addrnumber = @std_address_ids-address_id
      INTO TABLE @DATA(email_address2).
Das kann doch eigentlich gar nicht sein, denn in der zweiten Version liest Du eine ganz andere Datenbanktabelle als in der ersten?! Es sei denn, es gibt zwischen den Inhalten dieser Datenbanktabellen Konsistenzabhängigkeiten, die ich nicht kenne (die Tabelle but021_fs sehe ich zum ersten Mal).

Ich hätte folgendes gemacht:

Code: Alles auswählen.

REPORT ZTEST3.

TYPES: BEGIN OF KOMISCHER_DATENTYP,
         ADDRESS_ID TYPE ADR6-ADDRNUMBER,
         BUSINESS_PARTNER_ID TYPE BU_PARTNER,
         EMAIL_ADDRESS TYPE AD_SMTPADR,
       END OF KOMISCHER_DATENTYP,

       BEGIN OF EMAIL_ADDRESSES,
         ADDRESS_ID TYPE ADR6-ADDRNUMBER,
         BUSINESS_PARTNER_ID TYPE BU_PARTNER,
         EMAIL_ADDRESS TYPE AD_SMTPADR,
       END OF EMAIL_ADDRESSES.

DATA: ADDRESS_IDS TYPE HASHED TABLE OF KOMISCHER_DATENTYP WITH UNIQUE KEY ADDRESS_ID,
      EMAIL_ADDRESSES TYPE HASHED TABLE OF EMAIL_ADDRESSES WITH UNIQUE KEY ADDRESS_ID.

SELECT ADDRNUMBER, SMTP_ADDR FROM ADR6
  FOR ALL ENTRIES IN @ADDRESS_IDS
  WHERE ADDRNUMBER = @ADDRESS_IDS-ADDRESS_ID
  INTO TABLE @DATA(TEMP_TABLE).

EMAIL_ADDRESSES = VALUE #( FOR <ZEILE> IN TEMP_TABLE ( ADDRESS_ID = <ZEILE>-ADDRNUMBER
                                                       BUSINESS_PARTNER_ID = ADDRESS_IDS[ ADDRESS_ID = <ZEILE>-ADDRNUMBER ]-BUSINESS_PARTNER_ID
                                                       EMAIL_ADDRESS = <ZEILE>-SMTP_ADDR ) ).
FREE TEMP_TABLE.
Ob das tatsächlich langsamer ist als der JOIN über die interne Tabelle, das wäre nochmal nachzuprüfen; da bin ich keineswegs überzeugt. Ich räume allerdings ein, dass der JOIN kosmetisch schöner ist. Viel nimmt es sich in meinen Augen aber nicht.

Bei Deiner Lösung (in Deinem ursprünglichen Post) fehlt mir (wie leider in so vielen Frageposts) die Typisierung der verwendeten Felder und Tabellen. Vor allem wäre interessant gewesen, wie Deine interne Tabelle address_ids deklariert ist. Wenn die nicht SORTED oder HASHED über die Spalte address_id ist, dann machst Du bei jedem Durchlauf Deiner SELECT-Schleife eine sequenzielle Suche über die address_ids. Dass das nicht performant sein kann, liegt auf der Hand.

Was mir auch nicht gefällt, ist Dein Tabellenaufbau über VALUE #( BASE email_addresses ... . Technisch gesehen erzeugst Du damit bei jedem einzelnen Schleifendurchlauf eine komplett neue interne Tabelle. (Wenn die Zieltabelle email_addresses sortiert oder gehasht ist, dann baut er dabei zudem jedesmal komplett neu die Sortierung bzw. Hashung auf!) Das halt ich nicht nur für unperformant, sondern auch beim Lesen für schwerer zu verstehen als die Notation:

Code: Alles auswählen.

APPEND VALUE #( address_id = email_address-addrnumber
                business_partner_id = address_ids[ address_id = email_address-addrnumber ]-business_partner_id
                email_address = email_address-smtp_addr )
  TO email_addresses.
Letztlich willst Du bei jedem Schleifendurchlauf ja nur eine Zeile an Deine bereits aufgebaute interne Tabelle anhängen. Mit diesem APPEND tust Du das technisch und zeigst zugleich dem Leser Deines Codes deutlich, dass Du genau das tun willst.

Ich bin auch kein Fan davon, dass Du Deine Ergebnistabelle email_adresses (auch in der letzten Lösung) per Inline-Deklaration erzeugst. Das wäre allenfalls dann ok, wenn Du diese Tabelle anschließend als ALV oder anderweitig so, wie sie ist, ausgeben möchtest. Ich vermute aber, dass Du sie im weiteren Verlauf nutzen möchtest, um per

Code: Alles auswählen.

emailadresse = email_addresses[ address_id = whatever ]-smtp_addr.
zu verschiedenen Leuten die Emailadresse zu holen. Und dann ist es Mist, wenn email_addresses eine unsortierte Standardtabelle ist. Das sollte einem dann schon die paar Zeilen Code für eine konventionelle Deklaration wert sein.

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


Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von tm987456 (ForumUser / 60 / 36 / 12 ) » 26.10.2020 13:51
Typisierung ist angegeben. Zu oft diese Hinweise von dir gelesen ;) Key ist Partner, da ich das für andere Zugriffe brauche.

BUT021_FS ist die Verknüpfungstabelle zwischen Geschäftspartner und Adresse. Ich habe sie als Ersatzlösung in den Select aufgenommen, weil STD_ADDRESS_IDS eine echte Teilmenge von BUT021_FS ist.

Die For-Schleife ist auch eine schöne Lösung. Allerdings ging es mir ja darum eine zusätzliche Schleife zu vermeiden. SELECT, LOOP und FOR nimmt sich da glaube ich nicht so viel.

Das es technische unterschiede zwischen #value (Base ... und APPEND value #(... gibt war mir gar nicht bewusst. Habe meist erstere Variante gewählt, weil es für mich schöner/lesbarer war. Klingt sinnvoll was du dazu sagst, werde mir das noch mal genau anschauen.

Ergebnistabelle dynamisch erstellt habe ich nur für das Beispiel. Die im Programm verwendeten Tabellen sind natürlich sorted ;)

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von tm987456 (ForumUser / 60 / 36 / 12 ) » 26.10.2020 13:58
Horst Keller über value:
https://blogs.sap.com/2014/09/29/abap-n ... pressions/

Code: Alles auswählen.

t2 = VALUE #( BASE t1 ( 4 ) ).

"works as

CLEAR t2.

t2 = t1.

INSERT 4 INTO TABLE t2.

Damit wird es wohl zukünftig wieder APPEND. Danke D&P!

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von DeathAndPain (Top Expert / 1466 / 162 / 331 ) » 26.10.2020 17:56
Die For-Schleife ist auch eine schöne Lösung. Allerdings ging es mir ja darum eine zusätzliche Schleife zu vermeiden. SELECT, LOOP und FOR nimmt sich da glaube ich nicht so viel.
Doch! SELECT-Schleifen holen zeilenweise die Ergebnisse aus der Datenbank. Du hast also pro Zeile eine Kommunikation mit der Datenbank. Ich bin nicht sicher, inwieweit ABAP das mit Pufferungen abschwächt, aber im Prinzip setzt eine SELECT-Schleife einen CURSOR und FETCHt dann Zeile für Zeile die Ergebnisse.

Datenbankzugriffe aber sind teuer. Deswegen ist es eigentlich immer günstiger, die gewünschten Daten en bloc per INTO TABLE aus der Datenbank zu holen und anschließend nur noch lokal im Arbeitsspeicher zu arbeiten. Ob man dort dann mit LOOP, mit FOR oder mit was anderem (WHILE, DO, ...) loopt, ist dann vergleichsweise egal. Wichtig ist nur, nach Möglichkeit jegliche Suchbedingungen innerhalb jener internen Tabellen auf entsprechende Indizes durchzuführen. Die ABAP-Befehle LOOP, FOR usw. kosten nicht nennenswert Rechenzeit, ineffiziente Suchen hingegen schon!
Key ist Partner, da ich das für andere Zugriffe brauche.
Was bedeutet, dass der Key für die Schleife in Deiner Ursprungslösung nicht zu gebrauchen war und dort dann also sequentiell wie in einer Standardtabelle gesucht worden ist. Tipp: Für Fälle wie diesen ist es möglich, interne Tabellen mit mehreren Schlüsseln auszustatten.
Ich wusste zwar nicht, dass er das so gesagt hat, aber es ergibt sich logisch aus der Syntax. Wenn Du eine Zuweisung

Code: Alles auswählen.

ergebnistabelle = ...
schreibst, dann wird der bisherige Wert von ergebnistabelle verworfen und durch das auf der rechten Seite ersetzt. Auch wenn dort ein BASE steht, wird dennoch die Tabelle neu aufgebaut - einschließlich Hashschlüsseln bzw. Sortierung.

{rant}Dementsprechend braucht man davor auch keinen CLEAR. Das regt mich immer auf, wenn ich sehe, wie manche Leute aus panischer Angst, mit alten Feldwerten weiterzuarbeiten, ihren Code mit sinnlosen CLEAR-Befehlen zukleistern. Insbesondere ist jeder CLEAR vor einer direkten Zuweisung wie dieser für die Katz (außer wenn die Zielvariable auch auf der rechten Seite der Zuweisung auftaucht, was in Deinem BASE-Fall natürlich der Fall wäre). Für mich hat das auch eine meinungsbildende Bedeutung. Wenn ich:

Code: Alles auswählen.

CLEAR abc.
abc = def(4) && `01`.
sehe, dann schließe ich daraus, dass ich Code eines Programmierers vor mir habe, der in blind eingehämmerten Mustern programmiert, anstatt darüber nachzudenken, was er schreibt. Aber ich schweife ab. Du hast Dir in dieser Richtung ja nichts zuschulden kommen lassen. 😊{/rant}

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von black_adept (Top Expert / 3446 / 68 / 673 ) » 27.10.2020 11:52
DeathAndPain hat geschrieben:
26.10.2020 17:56
{rant}Dementsprechend braucht man davor auch keinen CLEAR. Das regt mich immer auf, wenn ich sehe, wie manche Leute aus panischer Angst, mit alten Feldwerten weiterzuarbeiten, ihren Code mit sinnlosen CLEAR-Befehlen zukleistern. Insbesondere ist jeder CLEAR vor einer direkten Zuweisung wie dieser für die Katz (außer wenn die Zielvariable auch auf der rechten Seite der Zuweisung auftaucht, was in Deinem BASE-Fall natürlich der Fall wäre). Für mich hat das auch eine meinungsbildende Bedeutung. Wenn ich:

Code: Alles auswählen.

CLEAR abc.
abc = def(4) && `01`.
sehe, dann schließe ich daraus, dass ich Code eines Programmierers vor mir habe, der in blind eingehämmerten Mustern programmiert, anstatt darüber nachzudenken, was er schreibt. Aber ich schweife ab. Du hast Dir in dieser Richtung ja nichts zuschulden kommen lassen. 😊{/rant}
Wobei mir Leute lieber sind, die vorsichtshalber ein CLEAR schreiben als solche die es dann mal irgendwo vergessen wo es wichtig ist. Wahrscheinlich ist das einfach im Muskelgedächtnis der Finger verankert.
Und ich frage mich gerade wie gut der Compiler von ABAP ist - der könnte solch ein offensichtlich überflüssiges Konstrukt doch intern optimieren.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de


Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von black_adept (Top Expert / 3446 / 68 / 673 ) » 27.10.2020 12:13
Wer legt denn so einen sinnlosen Check an? Habe selten etwas Überflüssigeres gesehen.
Dass so eine Prüfung sehr gut in anderen Programmiersprachen zu gebrauchen ist welche nicht mit impliziter Initialisierung wie ABAP ( z.B. Java ) arbeiten steht außer Frage - aber dieses Konzept auf ABAP übertragen zu wollen scheint auf ein Unwissen dieser ABAP-Eigenschaft hinzudeuten.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: SELECT, Inhalt aus FOR ALL ENTRIES in Zieltabelle übernehmen

Beitrag von DeathAndPain (Top Expert / 1466 / 162 / 331 ) » 27.10.2020 13:00
Genau so sehe ich das auch. DATA löscht definitionsgemäß den Variableninhalt, beinhaltet also gewissermaßen ein CLEAR. Jedenfalls ist es bei Methoden und Formroutinen so. (Für Leute, die das im Einzelfall nicht wollen, gibt es ja extra den STATICS-Befehl.) Nicht so ist es bei globalen Variablen (etwa von Funktionsbausteinen, denn da haben sie die Funktion statischer Klassenattribute, wie Funktionsbausteine ja generell den Charakter statischer Klassen haben (freilich ohne Vererbung)).

Insofern wundert es mich auch etwas, dass Horst Keller

Code: Alles auswählen.

t2 = VALUE #( BASE t1 ( 4 ) ).

"works as

CLEAR t2.

t2 = t1.

INSERT 4 INTO TABLE t2.
geschrieben haben soll, denn das ist ja auch so ein Mist mit einem völlig sinnlosen CLEAR. Allerdings konnte ich den zitierten Codeabschnitt in tm987456's Link https://blogs.sap.com/2014/09/29/abap-n ... pressions/ nicht wiederfinden.
black_adept hat geschrieben:Wobei mir Leute lieber sind, die vorsichtshalber ein CLEAR schreiben als solche die es dann mal irgendwo vergessen wo es wichtig ist.
Ich verstehe Deinen Gedankengang, aber nach meiner Erfahrung geht er in der Praxis nicht auf. An entscheidender Stelle wird dann doch das CLEAR vergessen - oder es werden andere Fehler gemacht, bei denen der kritische Leser klar erkennen kann, dass blind Schablonen angewendet wurden, anstatt sich geistig klar darüber zu werden, was man da programmiert.
black_adept hat geschrieben:Wahrscheinlich ist das einfach im Muskelgedächtnis der Finger verankert.
Man kann das geistige Dabeisein-bei-dem-was-man-codet nicht durch Dressierte-Affen-Methodik ersetzen, jedenfalls nicht unter Aufrechterhaltung desselben Qualitätsniveaus. Dafür ist Programmieren zu anspruchsvoll.
black_adept hat geschrieben:Und ich frage mich gerade wie gut der Compiler von ABAP ist - der könnte solch ein offensichtlich überflüssiges Konstrukt doch intern optimieren.
Das ist die Frage, ob es die Aufgabe des Compilers ist, schlampigen Code zu optimieren. Die Philosophie in SAP scheint ja doch eine andere zu sein, denn die Erweiterte Programmprüfung und der Code Inspector weisen einen ja auf jeden Furz hin, auch wenn man da teilweise sicherlich auch automatisiert optimieren könnte. Ich finde es aber auch richtig so. Ausgeführt werden sollte, was programmiert wurde.

Dann würde ich es besser finden, wenn man beim Generieren einen Fehler oder zumindest eine Warnung bekommen würde. Normalerweise nerven mich ja die oberlehrerhaften Warnungen, zu denen mutwilligerweise kein Pragma eingebaut wurde. Aber an dieser Stelle würde ich es gut finden, wenn den Leuten das gelbe Ausrufezeichen permanent um die Ohren gehauen wird und sie das Problem nur lösen können, indem sie den nutzlosen CLEAR beseitigen.


Aktuelle Forenbeiträge

Loop in der Endroutine
vor 4 Stunden von Mephisto1986 4 / 89
SELECT-OPTIONS ... FOR TYPE?!?
vor 18 Stunden von black_adept 20 / 628
Hierarchische Auswahl bei N:N
vor 19 Stunden von DeathAndPain 4 / 44

Vergleichbare Themen

Select mit all entries !!!!!
von Apabtalker » 01.04.2010 12:55
SELECT mit FOR ALL ENTRIES
von Marduk » 30.09.2005 12:55
Select for all entries in itab_suchwerte
von Anfänger » 12.07.2010 23:13
Select Abfrage - For all Entries
von Cargo2 » 09.12.2016 10:56
select all entries in itab
von spot » 23.11.2004 17:15