Interne Tabelle um Felder aus SAP-Tabelle ergänzen

Re: Interne Tabelle um Felder aus SAP-Tabelle ergänzen

Hallo,

dafür gibt es den Befehl 'Select', im Report auf Select mal die F1-Taste
dann bekommst du alle Möglichkeiten dazu.

Gruß Wolfgang

Re: Interne Tabelle um Felder aus SAP-Tabelle ergänzen

Strikte Syntax (die hier nicht geboten wäre; die @ und das Komma könntest Du einfach weglassen) und dann aber SELECT-ENDSELECT und die alte READ TABLE-Syntax. Das gefällt mir stilistisch und von der Performance her nicht. Man sollte nach Möglichkeit SELECT INTO TABLE machen, dann hat man alles mit einem einzigen Datenbankzugriff, und dann macht man im Hauptspeicher weiter.

Im übrigen haut Dein Code nicht hin, weil dieselbe KUNNR bei mehreren Einträgen der gt_nast als Partner vorkommen könnte. Schon deshalb musst Du über die gt_nast loopen; Deine SELECT-Schleife über die KNA1 erwischt immer nur den ersten Eintrag aus der gt_nast, in dem diese Kundennummer als Partner drinseht.

So würde ich es machen:

Re: Interne Tabelle um Felder aus SAP-Tabelle ergänzen

Ja, aber das geht Hand in Hand, weil die neue Syntax in vielen Fällen - so auch hier - auch kürzer und besser lesbar ist. Ich bemühe mich immer, anderen möglichst modernen Code vorzuschlagen, denn wer hier fragt, will dazulernen, und da finde ich es wichtig, dass die Leute sich gar nicht erst den alten Kram antrainieren. Ähnlich mit der Performance: Wer sich angewöhnt, immer von der Datenbank zu lesen, weil er das einst so gezeigt bekommen hat, für den ist es eine hohe Hürde, sich später umzustellen. Besser, man lernt es gleich richtig, damit sich die richtige Geisteshaltung beim Herangehen an Programmieraufgaben ausprägt. Dann macht man es irgendwann richtig ohne nachzudenken.

Ich selber habe die Umstellung vor ungefähr zwei Jahren gemacht. Bis dahin hatte ich auch fast alles immer aus der Datenbank gelesen, gerne auch im LOOP per SELECT SINGLE für jeden einzelnen Mitarbeiter. Spart Hauptspeicher, habe ich gedacht, ich will das System ja nicht ins Swappen zwingen. Dann habe ich einen neuen Kollegen bekommen, der es anders gemacht hat und die Daten gepuffert hat. Als ich seinen Code gesehen habe, war meine erste Reaktion "So eine Speicherverschwendung!". Dann habe ich darüber ausgedacht, wieviel das eigentlich ausmacht und bin zu dem Ergebnis gekommen, dass es wohl einige zehntausend Bytes sein werden. Tja, und dann habe ich mir überlegt, wie heutige Hauptspeichergrößen aussehen und wie lächerlich das ist und wieviel nach meiner eigenen Erfahrung Datenbankzugriffe kosten, und daraufhin habe ich meine ganze Programmierung umgestellt, was eine massive Umgewöhnung war.

Oder ein anderes Beispiel: In meiner Firma gibt es eine komplette Entwicklerabteilung in einem anderen SAP-Modul (da bin ich also nicht Teil von, aber man redet natürlich mal miteinander). Da dort ungarische Notation gang und gäbe ist, habe ich deren Chef (selber Entwickler) mal mit den Argumenten dagegen konfrontiert (sowohl mit Ralfs als auch mit den offiziellen Codedesignrichtlinien von der SAP). Er war aufgeschlossen, hat sich das angeschaut und hat es als Thema in ein Meeting mit seinen Entwicklern mitgenommen. Das Ergebnis war die Aussage, dass ich zwar von der Sache her recht hätte, dass das Team sich aber entschieden hätte, bei der ungarischen Notation zu bleiben, weil sie es halt alle so gewohnt sind.

Deshalb halte ich es für sehr wichtig, die Sachen immer gleich richtig zu unterrichten, denn wer es mal falsch gelernt hat, hat eine hohe Trägheitshürde, sich später noch umzustellen. Und es ist nicht zur Trägheit, sondern auch Psychologie. Niemals gesteht sich gerne ein, dass das, was er all die Jahre gemacht hat, schlecht gewesen ist. Das verdrängt man gerne oder redet es sich schön.

Re: Interne Tabelle um Felder aus SAP-Tabelle ergänzen

So wie die Thermodynamik Entropie als chaotischen Energiezustand definiert, definiert Zilberfeld Entropie als Chaos im Coding.

Das trifft es nämlich ziemlich gut. Wer sich mit Thermodynamik ein bisschen auskennt, weiß das Entropie bei allen Umwandlungen von thermischer in mechanischer Energie entsteht (Verbrennungsmotoren usw.).

Tatsächlich wird ja sogar angenommen, dass die Entropie im Universum laufend zunimmt, dass es sich dabei sogar um ein Naturgesetz handelt.

Wenn wir unsere Motoren von vor 20 Jahren mit den heutigen vergleichen, hat sich der Verbrauch pro PS um einiges reduziert und damit auch die erzeugte Entropie.

Ist das wirklich so, oder handelt es sich dabei nur um Werbemärchen? Wenn ich mir anschaue, was mein 17 Jahre alter Diesel verbraucht und was PS-gleiche Diesels heute verbrauchen, dann ist da nicht wirklich ein Unterschied. Wenn überhaupt, sind die Unterschiede marginal. Man kann nun mal nur begrenzt viel aus solch Verbrennung herausholen, und vor 20 Jahren hatte der Dieselmotor bereits viele Jahrzehnte Entwicklungszeit auf dem Buckel und war durchaus als ausgereift einzuschätzen.

Effizienz versucht man heutzutage mit Hybridmotoren herauszuholen, was bedingt funktioniert. In der Stadt ja wegen der Rekuperation, auf der Autobahn ist der Verbrenner dann allerdings wieder effizienter, besonders wenn man gerne mal schneller fährt.

Aus gutem Grund aber wird der geringere Verbrauch praktisch nie als Grund angeführt, weshalb man sich ein neues Auto kaufen solle. Die Zeiten, in denen in dem Bereich nennenswert was zu holen war, sind längst vorbei. Deswegen versucht man ja jetzt, den Markt mit immer strengeren Abgasnormen und Fahrverboten anzukurbeln, um die schwächelnde Wirtschaft zu stützen.

Aber wir schweifen ab.

Genau das ist auch in der ABAP-Entwicklung zu beobachten. Es gibt einen rasanten technischen Fortschritt, der es uns ermöglicht, sauberer und nachhaltiger zu entwickeln und damit Herr über eine schnell wachsende Menge Codings zu bleiben und der uns dabei hilft, dass der Code nicht irgendwann zum einem reinen Chaos verkommt.

Zu großen Teilen hast Du recht, und gerade die neue 7.40-Syntax hilft hier sehr. Es gibt allerdings auch große Bereiche, in denen die Neuerungen ihre gewünschte Wirkung verfehlt haben oder sich sogar als kontraproduktiv erweisen. Ein gutes Beispiel ist ABAP OO. Die Idee ist, durch Kapselung und Abstraktion komplexe Codeprobleme beherrsch- und wartbar zu machen, und richtig eingesetzt ist dies auch möglich. ABAP OO ist aber so gestaltet, dass es auch erhebliche Nachteile gegenüber der klassischen prozeduralen Programmierung bietet, Nachteile, die meines Erachtens problemlos vermeidbar gewesen wären. Das fängt mit der erzwungenen Trennung von Definition und Implementation an, deren Rechtfertigung rein akademischer Natur ist und die in der Praxis lediglich bewirkt, dass man dort, wo eine Unterroutine ausprogrammiert ist, nicht mehr sieht, welche Parameter rein- und rausgehen (was bei einer klassischen Formroutine immer am Anfang steht). Das hat dazu geführt, dass in der SE24 mit hohem Aufwand eine optische Darstellung gebaut worden ist, bei der man die Parameter immer eingeblendet bekommt (für den Preis verschenkten Bildschirmplatzes). In Eclipse kann man dies nicht nutzen; da muss man immer am anderen Ende des Codes nachsehen, wie die Schnittstelle beschaffen ist.

Auch die Tatsache, dass Methoden immer vor der Stelle stehen müssen, an der sie aufgerufen werden, weil der Interpreter sie sonst nicht findet, ist eine geradezu mutwillig eingebaute Beschränkung, die es bei klassischen Formroutinen nicht gibt und bei der auch kein Sinn erkennbar ist. Das führt dann auch zu so seltsamen Blüten wie dem Schlüsselwort DEFINITION DEFERRED.

Die Kapselung ist ein wichtiges Element in objektorientierter Programmierung. Allerdings gab es sie auch schon zu prozeduralen Zeiten, und auch ein gutes prozedurales Programm ist sauber gekapselt. Allerdings gab es damals auch noch globale Variablen. Die sollte man nicht einsetzen, wurde aber doch immer wieder gemacht. Man hätte denken sollen, dass zumindest dieser Zopf mit der Einführung objektorientierter Programmierung endlich abgeschnitten worden wäre, doch weit gefehlt: In Klassen hat man neue globale Variablen eingeführt, und damit es nicht auffällt, hat man sie "Attribute" genannt. Heute verwendet jeder sie (aus Faulheit) genau so, wie man früher globale Variablen verwendet hat, setzt damit klassenintern die gesamte Kapselung außer Kraft, und nichts ist gewonnen. OO-Apologeten halten einem gerne die akademische Theorie entgegen, die hinter dem Konzept von Klassenattributen stehen, aber das ändert nichts an der Praxis, die so aussieht, dass nahezu alle Attribute, die einem in der Praxis begegnen, einfach nur den Zweck globaler Variablen erfüllen, die man in jeder Methode verwenden kann, ohne dass sie Teil des Methodeninterfaces sind, so dass keiner nachvollziehen kann, wo ihr Wert herkommt und wo er hingeht und wie die Methoden dementsprechend miteinander kommunizieren.

Als Folge des Ganzen sind fremde objektorientierte Programme deutlich schwerer zu verstehen als fremde prozedurale Programme. Vor allem der Debugger ist zum Gewinn von Programmverständnis in Klassen bedeutend weniger nützlich als in herkömmlichen Programmen. Als Vorteil kann man anführen, dass Klassen und ihre Methoden sich viel besser isoliert testen und validieren lassen als Formroutinen, aber das setzt voraus, dass das Sollverhalten dieser Klassen und Methoden ganz sauber dokumentiert ist. Dazu sind die meisten Programmierer schon sprachlich nicht in der Lage (nur wenige Menschen können gut mit Sprache umgehen), und die meisten machen sich ohnehin nicht die Mühe. Klassen und Methoden sind in ihrer Verwendung aber so etwas wie selbst definierte ABAP-Befehle. Das kann sie sehr mächtig machen, aber wenn es ein fremdes Programm ist und man nicht weiß, was diese Methode eigentlich machen soll, wird das Programm sehr schwer verständlich, denn im Gegensatz zu einem echten ABAP-Befehl kann man nicht einfach in der F1-Hilfe nachlesen. Bei einem prozeduralen Programm hat man immer die Chance, mit dem Debugger nachzuvollziehen, was da in der Unterroutine eigentlich passiert, und meistens kann man da auch was erkennen. Wird jedoch mit Objekten hantiert, deren genaue Bedeutung und Verhalten man nicht kennt, dann hat man da kaum eine Chance. Die Forderung, alles müsse bestens dokumentiert sein, ist gut und berechtigt, aber auch akademisch und praxisfern, denn keiner macht es, und das ist die Realität, ob sie uns gefällt oder nicht.

Insofern gilt für Teile des neuen ABAPs, dass sie super sind, für andere Teile allerdings das Prinzip: "Gut gedacht und schlecht gemacht."

Ich kann es mir nicht verkneifen, an dieser Stelle mal wieder mein Lieblingszitat wiederzugeben (das nicht von mir stammt): "I don’t know the answer but I do know that debugging what happens after pressing a command in VA01 is easier to follow than the equivalent in ME21N. Or is that just because I am an OO novice?"

Re: Interne Tabelle um Felder aus SAP-Tabelle ergänzen

FREE gibt den Speicherplatz der internen Tabelle kunde_und_gesellschafter frei.
Die Anweisung ist optional. Die Speicherfreigabe übernimmt die ABAP-Laufzeitumgebung automatisch.