SMEN_BUFFC - falsches menu_level

Re: SMEN_BUFFC - falsches menu_level

Das wird damit zusammenhängen, dass es da Konsistenzabhängigkeiten geben wird und vermutlich an dieser Favoritenablage noch weitere Tabellen beteiligt sind. Ich habe mir die Tabelle SMEN_BUFFC angeschaut und Deine Gedankengänge verstanden. Der entscheidende Fehler, den Du hier machst, ist, hart in SAP-Standardtabellen zu schreiben. Das ist höchst unprofessionell und ein absolutes No-Go, denn nur die SAP kennt alle Abhängigkeiten und Zusammenhänge und kann zweifelsfrei sagen, was wie zusammenhängt und was zu beachten ist, damit ein Tabelleneintrag keine Konsistenzbedingungen in anderen Tabellen verletzt. Ich habe jetzt zwar nicht recherchiert, welche andere Tabelle das in diesem Fall wäre, aber sie muss ja eigentlich existieren, sonst wäre das von Dir beobachtete Systemverhalten nicht möglich.

Genau aus diesem Grund darf man zwar SAP-Tabellen lesen, muss sich zum Schreiben aber immer von der SAP gebotene Wege suchen, sei es ein BADI, sei es ein Funktionsbaustein oder zur Not ein programmierter Batch Input.

Wenn Du es dennoch herausfinden willst, dann solltest Du mit der Transaktion ST05 einen SQL-Trace mitschneiden, während Du in einem anderen Fenster händisch solch Favoriten anlegst. Anschließend könntest Du in dem Trace dann genau sehen, welche Datenbanktabellen wie angesprochen worden sind. Aber ganz deutlich: Auch wenn Du genau glaubst zu wissen, wie bestimmte SAP-Datenbanktabellen funktionieren, kannst Du das nie beweisen, und selbst, wenn es stimmen sollte, könnte die SAP es im nächsten Support Package schon ändern, so dass Dein Programm plötzlich Murks macht und die Datenkonsistenz zerstört. Aus diesem Grunde ist direktes Schreiben in SAP-Tabellen immer Pfusch und kann ggf. ein gutes Argument sein Dich rauszuschmeißen. Ich kann Dir nur dringend nahelegen, Dich von dieser Geisteshaltung zu lösen und zu der professionellen Einstellung zu wechseln, dass alle Änderungen an von der SAP angelegten Datenbanktabellen auch mit von der SAP bereitgestellten Mitteln erfolgen sollte.

Im übrigen möchte ich anmerken, dass es mir Bauchschmerzen bereitet zu sehen, dass selbst hier im "ABAP für Anfänger"-Forum immer wieder total antiquierter Code geboten wird, bei dem ich mich frage, wird das echt noch so von irgendwem unterrichtet, oder warum machen die Leute das?

Das fängt schon bei Deinem ersten Befehl an: Der Befehl TYPE-POOLS ist schon seit vielen Jahren veraltet und bewirkt in heutigen Releases genau gar nichts mehr! Aus Kompatibilitätsgründen meckert ABAP nicht darüber, sondern ignoriert den Befehl einfach, wenn es ihn vorfindet. Probier es aus und lösche ihn ersatzlos aus Deinem Programm. Du wirst feststellen, dass sich dadurch nichts ändert.

Und das Füllen einer internen Tabelle, bei Dir geschehen, um den FB VRM_SET_VALUES damit zu beschicken... warum sparst Du Dir nicht einfach den ganzen LOOP und schreibst modern:
Oder noch viel schöner:
Viel kürzer, viel besser lesbar, und den DATA ls_folders brauchst Du auch nicht mehr, weil Du die ganze Workarea nicht mehr brauchst.

Dafür scheinbar modern ist die objektorientierte Programmierung in Deinem Programm. Nur fragt man sich, wofür Du in diesem Programm mit Objekten hantieren möchtest. Dementsprechend erzeugst Du ja auch nur konstant ein einziges. Die Klasse verwendest Du nur, um Unterprogramme darin unterzubringen. Versteh mich nicht falsch: Methodenaufrufe sind erheblich schöner und besser lesbar als alte FORM-Aufrufe. Aber wenn Du sie nur dafür brauchst, dann wäre eine statische Klasse (DEFINITION ABSTRACT FINAL) angemessener. Dann sparst Du Dir das CREATE OBJECT, und der Leser sieht sofort, dass er sich über Objekte und deren Unterschiede keine Gedanken machen muss und Du einfach nur Unterprogramme aufrufst.