Interne Tabelle um Felder aus SAP-Tabelle ergänzen

Getting started ... Alles für einen gelungenen Start.
11 Beiträge • Seite 1 von 1
11 Beiträge Seite 1 von 1

Interne Tabelle um Felder aus SAP-Tabelle ergänzen

Beitrag von Sonne1234 (ForumUser / 30 / 16 / 1 ) » 13.12.2019 10:51

Hallo zusammen,

ich habe bereits Felder bzw. Daten in eine interne Tabelle gt_nast selektiert. Ich möchte gerne das Feld vbund aus der SAP Tabelle kna1 zu meiner internen Tabelle ergänzen.

Und zwar immer dann, wenn das Feld parnr aus der Tabelle gt_nast dem Feld kunnr der Tabelle kna1 entspricht.

Beispiel:

Daten aus gt_nast
objky parnr
965484545 4

Daten in kna1
kunnr vbund
4 G104

Ich möchte gerne das meine Tabelle gt_nast anschließend die folgenden Daten enthält:
objky parnr vbund
965484545 4 G104

Ich habe momentan aber leider keinerlei Ansatz wie ich das anstellen soll.

Google konnte mir auch nicht so richtig weiterhelfen. Ich habe etwas zu Tabellen-Joins gefunden und verschachtelten Loops. Aber hier wusste ich nicht so richtig, wie ich die Umsetzung angehen soll.

Deshalb hoffe ich, dass ihr mir hier zumindest einen Tipp geben könnt.

Danke :)


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

Beitrag von wreichelt (Expert / 763 / 18 / 134 ) » 13.12.2019 11:13

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

Beitrag von jocoder (Specialist / 149 / 2 / 37 ) » 13.12.2019 11:19

Eine Lösung könnte mit SELECT FOR ALL ENTRIES funktionieren:

Code: Alles auswählen.

DATA: BEGIN OF kunde_und_gesellschafter,
  kunnr TYPE kunnr,
  vbund TYPE rassc,
END OF kunde_und_gesellschafter.

SELECT kunnr, vbund FROM kna1 
  INTO CORRESPONDING FIELDS OF  @kunde_und_gesellschafter
  FOR ALL ENTRIES IN @gt_nast
  WHERE kunnr = @gt_nast-parnr.

  LOOP AT gt_nast ASSIGNING FIELD-SYMBOL(<nachricht>) 
    WHERE parnr = kunde_und_gesellschafter-kunnr.
       <nachricht>-vbund = kunde_und_gesellschafter-vbund.
  ENDLOOP.

ENDSELECT.
P.s. ich habe den strikten OpenSQL-Syntax benutzt, daher die @ vor den Variablen.
Zuletzt geändert von jocoder am 16.12.2019 07:43, insgesamt 1-mal geändert.

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

Beitrag von DeathAndPain (Top Expert / 1270 / 139 / 291 ) » 13.12.2019 14:15

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:

Code: Alles auswählen.

TYPES: BEGIN OF kunde_und_gesellschafter,
  kunnr TYPE kunnr,
  vbund TYPE rassc,
END OF kunde_und_gesellschafter.

DATA kunde_und_gesellschafter TYPE HASHED TABLE OF kunde_und_gesellschafter WITH UNIQUE KEY kunnr.

SELECT kunnr vbund INTO TABLE kunde_und_gesellschafter FROM kna1 
  FOR ALL ENTRIES IN gt_nast
  WHERE kunnr = gt_nast-parnr.

LOOP AT gt_nast ASSIGNING FIELD-SYMBOL(<gt_nast>).
  <gt_nast>-vbund = VALUE #( kunde_und_gesellschafter[ kunnr = <gt_nast>-parnr ]-vbund OPTIONAL ).
ENDLOOP.
FREE kunde_und_gesellschafter.
Zuletzt geändert von DeathAndPain am 16.12.2019 12:05, insgesamt 1-mal geändert.

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

Beitrag von jocoder (Specialist / 149 / 2 / 37 ) » 16.12.2019 07:46

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
Das ist ein berechtigter Punkt.
Bezüglich der anderen Punkte:
Es ging ja nicht darum die maximale Performance und den neuesten Syntax in dem Beitrag zu zeigen, sondern vielmehr das Prinzip, wie die Lösung gestaltet werden kann.

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

Beitrag von DeathAndPain (Top Expert / 1270 / 139 / 291 ) » 16.12.2019 12:04

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.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 2):
abuma (16.12.2019 16:44) • Thomas R. (17.12.2019 06:29)


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

Beitrag von jocoder (Specialist / 149 / 2 / 37 ) » 16.12.2019 14:41

Eine interessante Idee fand ich in diesem Zusammenhang den Entropie-Ansatz von Gil Zilberfeld.
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.).
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.
D.h. aber nicht das die Konstrukteure von vor 20 Jahren alles falsch gemacht haben. Es fand in der Zwischenzeit nur eine technische Weiterentwicklung, die es uns inzwischen ermöglicht bessere Motoren zu bauen.
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.

Daher macht es immer Sinn, die eigene Trägheit zu überwinden und neue Techniken zu erlernen und einzusetzen, um Chaos zu vermeiden und nachhaltiger in der Entwicklung zu werden.

Folgende Benutzer bedankten sich beim Autor jocoder für den Beitrag (Insgesamt 3):
ewx (16.12.2019 15:48) • abuma (16.12.2019 16:44) • Thomas R. (17.12.2019 06:28)


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

Beitrag von DeathAndPain (Top Expert / 1270 / 139 / 291 ) » 16.12.2019 16:53

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

Beitrag von Sonne1234 (ForumUser / 30 / 16 / 1 ) » 18.12.2019 09:58

Hallo zusammen,

ich bin erst gerade dazu gekommen, mein Programm weiter zu bearbeiten.

Vielen Dank für eure Hilfe und den interessanten Austausch ;)

Ich weiß zwar noch nicht so ganz, wie ich auf folgenden Teil hätte selber kommen sollen und wie ich mir das merken soll. Aber ich fange ja gerade mal an^^

Code: Alles auswählen.

LOOP AT gt_nast ASSIGNING FIELD-SYMBOL(<gt_nast>).
  <gt_nast>-vbund = VALUE #( kunde_und_gesellschafter[ kunnr = <gt_nast>-parnr ]-vbund OPTIONAL ).
ENDLOOP.
FREE kunde_und_gesellschafter.
Und das FREE verwende ich genau wofür? Ich meine, kann die Tabelle nicht einfach bestehen bleiben. Auch wenn ich sie theoretisch nicht mehr benötige.

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

Beitrag von jocoder (Specialist / 149 / 2 / 37 ) » 18.12.2019 13:01

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

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

Beitrag von DeathAndPain (Top Expert / 1270 / 139 / 291 ) » 19.12.2019 08:48

Ich weiß zwar noch nicht so ganz, wie ich auf folgenden Teil hätte selber kommen sollen
Der Weg, wie man auf sowas kommt, besteht darin, dass Du Dir überlegst, was Du machen würdest, wenn Du der Computer wärst, Deine internen Tabellen auf einem Zettel zu stehen hättest und die von Dir gewünschte Tätigkeit händisch abwickeln würdest. Da weißt Du intuitiv, wie Du da rangehen würdest. Und genau das musst Du als ABAP-Befehle niederschreiben.

In Deinem Beispiel hast Du eine Liste (Tabelle) gt_nast. Bei der möchtest Du jede Zeile um einen passenden Wert aus einer anderen Tabelle ergänzen. Was würdest Du händisch machen? Du würdest Deinen Zettel, auf dem die Zeilen der gs_nast niedergeschrieben sind, Zeile für Zeile durchgehen und zu jeder Zeile auf dem KNA1-Zettel nachsehen, wie für den betreffenden Partner der VBUND lautet.

In ABAP bedeutet das einen LOOP über die gs_nast, denn LOOP ist der Befehl, der der Reihe nach jede Zeile einer internen Tabelle durchgeht und damit was veranstaltet.

Warum würdest Du keine Schleife über die KNA1 machen, wie es jocoders erster Gedanke gewesen ist? Weil Du dann zu jedem Kunden eine gs_nast suchst. Aber es kann ja mehrere Nachrichten mit demselben Kunden geben. Händisch würdest Du es intuitiv richtig machen. Wenn Du eine Schulklassenliste hättest und zu jedem Kind die Telefonnummer ergänzen wolltest, dann würdest Du auch nicht auf die Idee kommen, das Telefonbuch durchzugehen und bei jeder Nummer zu schauen, ob sie in Deiner Klassenliste vorkommt, sondern Du würdest die Klassenliste durchgehen und zu jedem Eintrag die Nummer aus dem Telefonbuch heraussuchen.

An dieser Stelle wird auch offensichtlich, dass es wichtig ist, dass die KNA1 (bzw. eine interne Tabelle, in der Du sie ggf. pufferst) sortiert ist, damit Du (bzw. der arme ABAP-Interpreter) nicht bei jeder einzelnen Zeile der gs_nast Zeile für Zeile ("sequentiell") durch die gesamte KNA1 rasen muss, sondern gezielt die benötigte Zeile finden kann. Deshalb sind Telefon- oder Wörterbücher auch alphabetisch sortiert. Sonst hättest Du händisch nämlich genau das gleiche Problem, wenn Du eine Telefonnummer oder ein Wort suchst.

Na ja, und wenn Du die LOOP-Schleife über die gs_nast machst, dann schaust Du halt für jede Zeile nach, welchen Wert Du dafür in der KNA1 findest. Nichts anderes macht der Code, den ich Dir vorgeschlagen habe, nur dass der aus Performancegründen vorher alle benötigten Zeilen in einem Rutsch in die (schon von jocoder angedachte) Puffertabelle kunde_und_gesellschafter liest, da Datenbankzugriffe teuer (langsam) sind und Du auf diese Weise hinterher schnell im Hauptspeicher suchen kannst. Du könntest das auch weglassen und innerhalb Deines LOOPs über die gs_nast einfach einen SELECT SINGLE auf die KNA1 machen. Wäre langsamer und würde Deine Datenbank stärker belasten, würde aber auch funktionieren.

Den FREE-Befehl sieht man selten. Im Prinzip macht er dasselbe wie CLEAR, gibt aber explizit auch den benötigten Hauptspeicher der internen Tabelle wieder frei (was CLEAR nicht tut!). Die Puffertabelle kunde_und_gesellschafter habe ich ja nur angelegt und gefüllt, um effizienter die Schleife über die gs_nast machen zu können und dabei nicht jedesmal einen SELECT SINGLE auf die Datenbank machen zu müssen. Nach Beendigung der Schleife über die gs_nast brauche ich den Inhalt dieser Hilfstabelle nicht mehr. Neben der Performanceoptimierung dient der FREE-Befehl auch als dokumentierender Hinweis für jeden, der diesen Code liest, dass die Tabelle kunde_und_gesellschafter im weiteren Programmverlauf nicht mehr benötigt werden wird.

Der Hauptgrund, weshalb FREE tatsächlich kaum benutzt wird, besteht darin, dass man Dateneinleseroutinen wie diese normalerweise in Unterroutinen (Methoden oder FORM-Routinen) verpackt. Dadurch gliedert man das Hauptprogramm und macht es besser lesbar. Wenn aber die Methode oder FORM-Routine endet, dann werden sowieso alle darin deklarierten Felder wieder freigegeben (außer, wenn man sie explizit mit STATICS deklariert), so dass der explizite FREE sich erübrigt.

Wer sich nicht die Mühe macht, sein Programm ordentlich in Unterroutinen zu gliedern, sondern Spaghetticode schreibt, der ist ein schlampiger Programmierer, der sich erst recht nicht darum scheren wird, dass seine nicht mehr benötigte Hilfstabelle weiterhin Hauptspeicher belegt und wird daher auch keinen FREE-Befehl nutzen.

Zuweilen schreibe ich aber Unterprogramme, die bestimmte Daten einlesen. Dabei muss ich nacheinander verschiedene Hilfsdaten lesen, um an die benötigten Hauptdaten zu kommen. So kann es passieren, dass ich nacheinander z.B. drei LOOP-Schleifen mit je 5 Zeilen Code darin habe. Macht zusammen 20 Zeilen Code für das Unterprogramm. Da sehe ich dann keine Notwendigkeit, jede dieser LOOPs nochmal in ein eigenes Unterprogramm zu packen. Wenn ich aber vor dem ersten LOOP eine Hilfstabelle fülle, diese dann benutze und nach dem LOOP nicht mehr brauche, dann streue ich schon mal vor dem zweiten LOOP ein FREE ein, um den Hauptspeicher nicht länger zu belegen als nötig.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Sonne1234 (08.01.2020 10:50)


Seite 1 von 1