Unterschiedliches Verhalten 7.02 / 7.50

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).
13 Beiträge • Seite 1 von 1
13 Beiträge Seite 1 von 1

Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von Murdock (Specialist / 115 / 55 / 8 ) »
Hallo,

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.
Kann mir jemand sagen, warum das alte Coding nicht mehr funktioniert?

Danke.

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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).

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


Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von Murdock (Specialist / 115 / 55 / 8 ) »
DeathAndPain hat geschrieben:
25.09.2019 09:48
Eigentlich sollte es weiterhin funktionieren (auch wenn ich noch nie einen SELECT direkt in ein Objektattribut gemacht habe).
Dachte ich mir eigentlich auch, aber leider funktioniert es so nicht.
DeathAndPain hat geschrieben:
25.09.2019 09:48
Aber irgendwie finde ich das seltsam programmiert.
Ja, finde ich auch :-)
DeathAndPain hat geschrieben:
25.09.2019 09:48
SELECT-ENDSELECT ist sowieso ziemlich oldschool und sollte möglichst vermieden werden, schon auch aus Performancegründen.
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:48
Allerdings hast Du beim Verlassen der SELECT-Schleife eine leere Instanz vom letzten CREATE OBJECT innerhalb des SELECT übrig. Ist das so gewollt!?
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.

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.

Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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'.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Murdock

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von Murdock (Specialist / 115 / 55 / 8 ) »
black_adept hat geschrieben:
25.09.2019 11:57
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'.
Die lokale Variable wurde immer korrekt selektiert und befüllt. Egal ob alte oder neue Version.
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.

Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von fr-g (ForumUser / 76 / 12 / 25 ) »
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...
Zuletzt geändert von fr-g am 25.09.2019 16:04, insgesamt 1-mal geändert.

Folgende Benutzer bedankten sich beim Autor fr-g für den Beitrag:
Murdock


Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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......

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 4):
MurdockDeathAndPainThomas R.SaskuAc

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.

Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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 ).
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Das Verhalten des neuen Systems macht für mich tatsächlich mehr Sinn als der des alten Systems
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.

Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Murdock hat geschrieben:
25.09.2019 08:04
Seit EHP8 werden die Objektattribute lc_pos->equnr und lc_pos->matnr nur noch beim ersten Select Durchlauf gefüllt, danach bleiben sie Initial.
Lustigerweise mit dem letzten Wert des SELECT...
Ich habe das Mal nachgestellt und kann das Verhalten bestätigen.

Re: Unterschiedliches Verhalten 7.02 / 7.50

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
DeathAndPain hat geschrieben:
26.09.2019 15:44
Das Verhalten des neuen Systems macht für mich tatsächlich mehr Sinn als der des alten Systems
Wieso soll das mehr Sinn machen?
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.
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):
DeathAndPainLegxis

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de


Seite 1 von 1

Vergleichbare Themen

4
Antw.
2232
Views
SUBMIT TO SPOOL - unterschiedliches Verhalten P01/E01
von miru77 » 21.02.2014 09:07 • Verfasst in ABAP® für Anfänger
1
Antw.
2501
Views
Startroutine, 2 interne Tabellen, unterschiedliches Format
von PeterB » 19.08.2005 09:39 • Verfasst in Sonstige Module
0
Antw.
1899
Views
Verhalten CL_GUI_TIMER
von current_user » 09.10.2011 20:27 • Verfasst in ABAP Objects®
1
Antw.
145
Views
Verhalten von ENQUEUE Bausteinen
von A6272 » 06.07.2023 12:18 • Verfasst in ABAP® für Anfänger

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.