Komische Meldung aus der Erweiterten Programmprüfung
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Hallo zusammen,
folgendes Statement in einem meiner Codes:
Die Erweiterte Programmprüfung meckert hier Folgendes an:
Was will er da von mir? Klar könnte ich <GESAMTBUCHUNGSPLAN>-ZU_VERBUCHENDE_ZEILEN mit VALUE #() umschließen, aber was soll das bringen? Dass es die Zeile gibt, ist gesichert (sonst würde ich das nicht so schreiben), und ich glaube ohnehin nicht, dass er das meint, sonst hätte er mir explizit OPTIONAL oder DEFAULT nahegelegt. Was aber soll ein VALUE #() hier sonst bringen!?
folgendes Statement in einem meiner Codes:
Code: Alles auswählen.
IF konto_fuer_periode_nutzbar( kontonummer = <gesamtbuchungsplan>-zu_verbuchende_zeilen[ 1 ]-quellkonto
periode = <gesamtbuchungsplan>-quellbeleg_budat(6) ) = abap_false.Code: Alles auswählen.
Warnung von der Syntaxprüfung.
Die Warnung wird nur innerhalb von SLIN angezeigt.
Der Zeilentyp von "<GESAMTBUCHUNGSPLAN>-ZU_VERBUCHENDE_ZEILEN" ist schmal und flach. Daher wird "VALUE
#( ... )" (Wertselektion) empfohlen.
Interner Meldungscode: MESSAGE GLP
Durch das Pragma ##OPERATOR[<GESAMTBUCHUNGSPLAN>-ZU_VERBUCHENDE_ZEILEN] deaktivierbar. Meldungscode: WRN 1305
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Normalerweise ist doch in der SLIN ein "i"-Button bei jeder Meldung, der genauer erklärt, warum die Zeile angemahnt wird. Mein Tipp ist (gerade kein Zugriff auf ein modernes System ), dass SAP der Meinung ist, dass der Compiler/Interpreter schneller ist, wenn du mit VALUE #() arbeitest statt einem MOVE. Lesbarer/Wartbarer wird es dadurch aber nicht.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Das war mir gar nicht bewusst, dass man auf dieses i draufklicken kann und dann ergänzende Informationen enthält. Deine Vermutung ist offenbar zutreffend. In diesem Fall erhalte ich Folgendes:
"Für einen Tabellenausdruck itab[ ... ] an dieser Stelle vergibt der Kompilierer "ASSIGNING"-Semantik, d.h. es wird ein internes Feldsymbol auf die selektierte Zeile gesetzt. Da der Zeilentyp aber schmal und flach ist, ist von einer Selektion mit "INTO"-Semantik (die Zeile wird in eine interne Variable herauskopiert) eine leicht bessere Laufzeit zu erwarten. Um dies zu erreichen, schließen Sie den gesamten Tabellenausdruck in den VALUE-Operator ein:
VALUE #( itab[ ... ] )"
Seit wann ist INTO schneller als ASSIGNING!? Das kannte ich immer andersherum.
Man kann diese Meldung per Pragma unterdrücken. Ich finde es aber absurd, dass sie überhaupt kommt. Man müsste sich mal den Spaß machen zu messen, wieviel Laufzeit das ausmacht, aber ich gehe davon aus, dass man den Unterschied (über dessen Existenz ich ohnehin staune) unter Ulk verbuchen kann.
"Für einen Tabellenausdruck itab[ ... ] an dieser Stelle vergibt der Kompilierer "ASSIGNING"-Semantik, d.h. es wird ein internes Feldsymbol auf die selektierte Zeile gesetzt. Da der Zeilentyp aber schmal und flach ist, ist von einer Selektion mit "INTO"-Semantik (die Zeile wird in eine interne Variable herauskopiert) eine leicht bessere Laufzeit zu erwarten. Um dies zu erreichen, schließen Sie den gesamten Tabellenausdruck in den VALUE-Operator ein:
VALUE #( itab[ ... ] )"
Seit wann ist INTO schneller als ASSIGNING!? Das kannte ich immer andersherum.
Man kann diese Meldung per Pragma unterdrücken. Ich finde es aber absurd, dass sie überhaupt kommt. Man müsste sich mal den Spaß machen zu messen, wieviel Laufzeit das ausmacht, aber ich gehe davon aus, dass man den Unterschied (über dessen Existenz ich ohnehin staune) unter Ulk verbuchen kann.
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
DAS, was du da gerade erlebst, ist der Grund, warum ich mir grundsätzlich die Erklärungen der SLIN-Fehlermeldungen von Zeit zu Zeit anschaue. Da ändert sich auch mal was und man lernt hin und wieder durchaus was neues. Aber alles mit Vorsicht genießen. Es gibt u.a. die Meldung, dass man doch bitte keine Tabellen oder komplexen Strukturen oder Strings als value-Parameter verwenden soll, da die Laufzeit angeblich um den Faktor bis zu 1000 (!!) langsamer wird. Das hatte ich mal mit den bei mir üblichen Datenstrukturen getestet und mich auf Grund der Analyse dazu entschieden diese Meldung grundsätzlich mittels Pragma wegzudrücken, genauso wie die meisten(alle?) SLIN-Meldungen bzgl. SELECT INTO CORRESPONDING .
In deinem speziellen Fall würde ich mir das als okkultes Grenzwissen im Hinterkopf behalten, wenn du mal irgendwas tolles und hochkomplexes irgendwo einbringen möchtest, aber es im Coding einfach so lassen, weil hier die Lesbarkeit doch stark abnimmt für einen wahrscheinlich zu vernachlässigenden Effekt.
In deinem speziellen Fall würde ich mir das als okkultes Grenzwissen im Hinterkopf behalten, wenn du mal irgendwas tolles und hochkomplexes irgendwo einbringen möchtest, aber es im Coding einfach so lassen, weil hier die Lesbarkeit doch stark abnimmt für einen wahrscheinlich zu vernachlässigenden Effekt.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
DeathAndPain • qyurryus
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Genau so sehe ich das auch, vielen Dank. Nur verschmutzen Pragmas halt das Coding optisch, so dass ich schon etwas genervt bin, sie für so einen Unsinn zu brauchen.
Seite 1 von 1
Vergleichbare Themen
15
Antw.
Antw.
1013
Views
Views
5
Antw.
Antw.
2645
Views
Views
Vom Dynpro (von...bis...) zu erweiterten Selektionen
von ralf.wenzel » 24.10.2012 08:54 • Verfasst in ABAP® Core
von ralf.wenzel » 24.10.2012 08:54 • Verfasst in ABAP® Core
2
Antw.
Antw.
1332
Views
Views
0
Antw.
Antw.
1571
Views
Views
1
Antw.
Antw.
1663
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 992
vor 2 Tagen von DeathAndPain 4 / 992
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 992
vor 2 Tagen von DeathAndPain 4 / 992