Unterschiedliches Verhalten 7.02 / 7.50
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
Hallo,
wir haben EHP8 eingespielt (von EHP5).
Bisher funktionierte folgendes Coding (btw. nicht von mir) ohne Probleme:
Seit EHP8 werden die Objektattribute lc_pos->equnr und lc_pos->matnr nur noch beim ersten Select Durchlauf gefüllt, danach bleiben sie Initial.
Ich habe das Coding jetzt so umgestellt und es funktioniert wieder:
Kann mir jemand sagen, warum das alte Coding nicht mehr funktioniert?
Danke.
wir haben EHP8 eingespielt (von EHP5).
Bisher funktionierte folgendes Coding (btw. nicht von mir) ohne Probleme:
Code: Alles auswählen.
create OBJECT lc_pos.
select equnr heqnr submt
into (lc_pos->equnr,lv_heqnr,lc_pos->matnr)
from equz
where hequi = parent->equnr and datbi gt sy-datum.
lc_pos->posnr = lv_heqnr.
append lc_pos to me->poslist.
create OBJECT lc_pos.
endselect.
Seit EHP8 werden die Objektattribute lc_pos->equnr und lc_pos->matnr nur noch beim ersten Select Durchlauf gefüllt, danach bleiben sie Initial.
Ich habe das Coding jetzt so umgestellt und es funktioniert wieder:
Code: Alles auswählen.
SELECT equnr, heqnr, submt
INTO @DATA(ls_equz2)
FROM equz
WHERE hequi = @parent->equnr AND datbi GT @sy-datum.
lc_pos->equnr = ls_equz2-equnr.
lc_pos->matnr = ls_equz2-submt.
lc_pos->posnr = ls_equz2-heqnr.
APPEND lc_pos TO me->poslist.
CREATE OBJECT lc_pos.
CLEAR ls_equz2.
ENDSELECT.Danke.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Eigentlich sollte es weiterhin funktionieren (auch wenn ich noch nie einen SELECT direkt in ein Objektattribut gemacht habe). Aber irgendwie finde ich das seltsam programmiert. Auf den ersten Blich sieht es so aus, als ob Du Objektattribute füllen würdest, bevor Du die Objektinstanz überhaupt erzeugt hast. Aber wegen des CREATE OBJECT, das vor dem SELECT steht, hast Du auch schon beim ersten Schleifendurchlauf eine Instanz.
Allerdings hast Du beim Verlassen der SELECT-Schleife eine leere Instanz vom letzten CREATE OBJECT innerhalb des SELECT übrig. Ist das so gewollt!?
SELECT-ENDSELECT ist sowieso ziemlich oldschool und sollte möglichst vermieden werden, schon auch aus Performancegründen. Besser ist eine interne Hilfstabelle nebst SELECT INTO TABLE, damit Du nur einen Datenbankzugriff hast und ab dann im lokalen Speicher weiterarbeitest. Dann kannst Du in einem LOOP Deine Objekte anlegen. Hinterher kannst Du per FREE den Speicher Deiner Hilfstabelle wieder freigeben, wenn Du sie nicht mehr brauchst (aber meist wird man das in einer Unterroutine machen, die anschließend endet, wodurch der Speicher sowieso wieder freigegeben wird).
Allerdings hast Du beim Verlassen der SELECT-Schleife eine leere Instanz vom letzten CREATE OBJECT innerhalb des SELECT übrig. Ist das so gewollt!?
SELECT-ENDSELECT ist sowieso ziemlich oldschool und sollte möglichst vermieden werden, schon auch aus Performancegründen. Besser ist eine interne Hilfstabelle nebst SELECT INTO TABLE, damit Du nur einen Datenbankzugriff hast und ab dann im lokalen Speicher weiterarbeitest. Dann kannst Du in einem LOOP Deine Objekte anlegen. Hinterher kannst Du per FREE den Speicher Deiner Hilfstabelle wieder freigeben, wenn Du sie nicht mehr brauchst (aber meist wird man das in einer Unterroutine machen, die anschließend endet, wodurch der Speicher sowieso wieder freigegeben wird).
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Murdock
Dachte ich mir eigentlich auch, aber leider funktioniert es so nicht.DeathAndPain hat geschrieben: ↑25.09.2019 09:48Eigentlich sollte es weiterhin funktionieren (auch wenn ich noch nie einen SELECT direkt in ein Objektattribut gemacht habe).
Ja, finde ich auch :-)
Das ist mir soweit klar, danke. Wie gesagt, dass Ursprungscoding ist nicht von mir sondern von einem externen Entwickler und ich musste jetzt erst mal schnell rauskriegen, warum das nicht mehr funktioniert (wir sind mit EHP8 bereits produktiv). Dass man dieses hier (und noch vieles andere) besser programmieren kann, ist jetzt erstmal zweitrangig, wichtig ist, dass es in der Produktion funktioniert.DeathAndPain hat geschrieben: ↑25.09.2019 09:48SELECT-ENDSELECT ist sowieso ziemlich oldschool und sollte möglichst vermieden werden, schon auch aus Performancegründen.
Mit Bezug zu dem was ich oben geschrieben habe: Dass ist mir momentan nicht so wichtig, ob der Entwickler das da mit Absicht so gemacht hat, oder nicht.DeathAndPain hat geschrieben: ↑25.09.2019 09:48Allerdings hast Du beim Verlassen der SELECT-Schleife eine leere Instanz vom letzten CREATE OBJECT innerhalb des SELECT übrig. Ist das so gewollt!?
Das Coding ist "mitten drin" und ich wollte erstmal so wenig wie möglich ändern, es aber lauffähig machen.
Danke für Deine Zeit und Mühe.
Zuletzt geändert von Murdock am 25.09.2019 12:50, insgesamt 1-mal geändert.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Kannst du nach dem create object innerhalb des Loops bitte mal den 3 Variablen, die im Select gefüllt werden explizit andere Werte zuweisen bevor die nächste SELECT-Zeile die Daten wieder füllt und berichten, ob sich das dann immer noch so verhält und ob auch die lokale Variable nur im 1. Durchlauf geändert wird.
Also nach dem inneren CREATE Object so was wie:
lc_pos->equnr = lc_pos->matnr = lv_hequnr = 'TEST'.
Also nach dem inneren CREATE Object so was wie:
lc_pos->equnr = lc_pos->matnr = lv_hequnr = 'TEST'.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Murdock
Die lokale Variable wurde immer korrekt selektiert und befüllt. Egal ob alte oder neue Version.black_adept hat geschrieben: ↑25.09.2019 11:57ob sich das dann immer noch so verhält und ob auch die lokale Variable nur im 1. Durchlauf geändert wird.
Also nach dem inneren CREATE Object so was wie:
lc_pos->equnr = lc_pos->matnr = lv_hequnr = 'TEST'.
Nach dem Zuweisen anderer Werte, wie von Dir vorgeschlagen, verhält sich der Select genauso wie vorher, also die Attribute werden nicht neu befüllt (der neu zugewiesene Wert bleibt erhalten).
Danke.
Ich habe das mal bei mir nachgestellt und er scheint halt immer die Attribute des zuerst erzeugten Objekts zu ändern. Der Select arbeitet also immer mit demselben Objekt und die Attribute der weiteren Objekte bleiben deshalb initial. Ich kann nur bestätigen, dass das Verhalten auftritt. Warum es unter 7.02 anders lief, kann ich (noch) nicht sagen :/
Edit: Das unterschiedliche Verhalten lässt sich analog auch mit Datenreferenzen/Feldsymbolen beobachten. Interessant...
Edit: Das unterschiedliche Verhalten lässt sich analog auch mit Datenreferenzen/Feldsymbolen beobachten. Interessant...
Zuletzt geändert von fr-g am 25.09.2019 16:04, insgesamt 1-mal geändert.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Hört sich nach einem Bug des Optimizers an.
Mein Tipp: Mach mal eine OSS-Anfrage auf mit Prio "hoch" und dann würde mich interessieren mit welcher Begründung SAP uns mitteilt, dass das so "works as designed" sein soll......
Mein Tipp: Mach mal eine OSS-Anfrage auf mit Prio "hoch" und dann würde mich interessieren mit welcher Begründung SAP uns mitteilt, dass das so "works as designed" sein soll......
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 4):
Murdock • DeathAndPain • Thomas R. • SaskuAc
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Definitiv ein Bug, wenn ich ihn auch nicht beim Optimizer sehe, denn der ist ja datenbankseitig. Hier aber geht es darum, dass der Application Server die empfangenen Daten in die falschen Datenfelder füllt.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Wobei ich bei längerem Nachdenken nicht sicher bin, ob der Bug im alten oder im neuen System ist. Das Verhalten des neuen Systems macht für mich tatsächlich mehr Sinn als der des alten Systems - aber man kann (leider) für beide Verhalten gute Gründe finden.
Was mich einfach stört ist, dass sich hier ein Verhalten einfach derart ändert ohne dass ich irgend wo eine Doku dazu gesehen hätte ( aber ich lese halt auch nicht alles und überall ).
Was mich einfach stört ist, dass sich hier ein Verhalten einfach derart ändert ohne dass ich irgend wo eine Doku dazu gesehen hätte ( aber ich lese halt auch nicht alles und überall ).
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Wieso soll das mehr Sinn machen? Wenn ein neuer Befehl create OBJECT lc_pos. kommt, dann muss danach lc_pos auf das neu erzeugte Objekt zeigen. Wenn man dann Attribute von lc_pos füllt, dann macht es nach meinem Verständnis überhaupt keinen Sinn, wenn die Werte dann in Attribute von Objektinstanzen gefüllt werden, auf die lc_pos früher mal gezeigt hat.Das Verhalten des neuen Systems macht für mich tatsächlich mehr Sinn als der des alten Systems
Lustigerweise mit dem letzten Wert des SELECT...
Ich habe das Mal nachgestellt und kann das Verhalten bestätigen.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Weil bei Schleifen recht häufig ein Wert beim Start der Schleife gemerkt wird. Wenn du ein DO X TIMES machst und X zwischendurch änderst wird die Schleife so oft durchlaufen wie am Anfang angegeben.DeathAndPain hat geschrieben: ↑26.09.2019 15:44Wieso soll das mehr Sinn machen?Das Verhalten des neuen Systems macht für mich tatsächlich mehr Sinn als der des alten Systems
Bei dem SELECT-Verhalten wird die INTO-Variable definiert. Und die zeigt halt beim auf die Instanzvariablen der 1. Instanz
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
DeathAndPain • Legxis
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
2474
Views
Views
SUBMIT TO SPOOL - unterschiedliches Verhalten P01/E01
von miru77 » 21.02.2014 09:07 • Verfasst in ABAP® für Anfänger
von miru77 » 21.02.2014 09:07 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
1823
Views
Views
Transaktion ME59n - unterschiedliches Verhalten bei Änderung Selektion
von ewx » 28.07.2020 11:13 • Verfasst in Material Management & Produktionsplanung
von ewx » 28.07.2020 11:13 • Verfasst in Material Management & Produktionsplanung
1
Antw.
Antw.
2658
Views
Views
Startroutine, 2 interne Tabellen, unterschiedliches Format
von PeterB » 19.08.2005 09:39 • Verfasst in Sonstige Module
von PeterB » 19.08.2005 09:39 • Verfasst in Sonstige Module
0
Antw.
Antw.
1995
Views
Views
1
Antw.
Antw.
259
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 / 1138
vor 2 Tagen von DeathAndPain 4 / 1138
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 / 1138
vor 2 Tagen von DeathAndPain 4 / 1138