export to Memory ID
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Hallo,
eine interne Tabelle wird per export to Memory ID weggeschrieben. Dies erfolgt 2 mal in unterschiedlichen Funktionsbausteinen die alle nacheinander von eimem Report aufgerufen werden.
Wird bei export to Memory ID die Tabelle im speicher überschrieben?
Gibt es eine Option die neuen Einträge anzuhängen (Ohne import...)?
eine interne Tabelle wird per export to Memory ID weggeschrieben. Dies erfolgt 2 mal in unterschiedlichen Funktionsbausteinen die alle nacheinander von eimem Report aufgerufen werden.
Wird bei export to Memory ID die Tabelle im speicher überschrieben?
Gibt es eine Option die neuen Einträge anzuhängen (Ohne import...)?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
ja.A6272 hat geschrieben: Wird bei export to Memory ID die Tabelle im speicher überschrieben?
Import - append lines to itab - exportA6272 hat geschrieben:Gibt es eine Option die neuen Einträge anzuhängen (Ohne import...)?
Ansonsten: Nein.
Zitat aus der Doku dazu:
Any existing data clusters with the same ID id are completely overwritten
goto http://lausek.eu;
irgendwie finde ich den EXPORT TO MEMORY suspekt. Ich dachte immer man soll global gehaltene Daten vermeiden? 
Gibt es jemanden, der das für seine (kunden)eigenen Porgramme verwendet ??
Grüße 4Byte
Gibt es jemanden, der das für seine (kunden)eigenen Porgramme verwendet ??
Grüße 4Byte
Es gibt 10 Menschen die binär verstehen 
Vermeiden heißt ja nicht, dass man es nicht mal brauchen könnte.4byte hat geschrieben:irgendwie finde ich den EXPORT TO MEMORY suspekt. Ich dachte immer man soll global gehaltene Daten vermeiden?
Gibt es jemanden, der das für seine (kunden)eigenen Porgramme verwendet ??
Grüße 4Byte
Ich verwende das immer mal wieder, wenn die Schnittstelle von BAdIs oder anderen Exits nicht ausreichend ist.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Ich halte das Ding für ein Relikt aus der Steinzeit. Habe ich schon zu Release 3.1i-Zeiten die Finger von gelassen. Programmglobale Variablen sind ja schon weitgehend geächtet, was soll man da erst von systemglobalen Variablen halten? Da holt sich ein Programm irgendwelche Daten aus dem Nirwana, und kein Schwein kann nachvollziehen, wer die da mal wann hinterlegt hat.
Und nein, Dokumentation ist nicht die Antwort auf so einen Pfusch.
Und nein, Dokumentation ist nicht die Antwort auf so einen Pfusch.
Dass es im Einzelfall ein gangbarer Weg sein kann, Unzulänglichkeiten des SAP-Standards auf diese Weise zu umgehen, bestreite ich nicht. Ich würde mir notfalls auch Feldinhalte aus in der Aufrufhierarchie höher liegenden Programmen erschleichen (Ausbruch aus der Sandbox per (Programmname)Variablenname). Vermeiden sollte man sowas aber um jeden Preis, und in meinen Augen gehört an jeden IMPORT FROM MEMORY ein umfassender Codekommentar, wer uns da was zu welchem Zweck im Memory hinterlassen hat.ewx hat geschrieben:Vermeiden heißt ja nicht, dass man es nicht mal brauchen könnte.
Ich verwende das immer mal wieder, wenn die Schnittstelle von BAdIs oder anderen Exits nicht ausreichend ist.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
ralf.wenzel
wenn man den export und den Import in einer Klasse kapselt, dann tut das überhaupt nicht weh.DeathAndPain hat geschrieben:Vermeiden sollte man sowas aber um jeden Preis, und in meinen Augen gehört an jeden IMPORT FROM MEMORY ein umfassender Codekommentar, wer uns da was zu welchem Zweck im Memory hinterlassen hat.
Dann kann man anhand des Verwendungsnachweises genau sehen, wo die Daten exportiert und wo sie wieder eingelesen werden.
Würde ich immer einem Dirty-Assign vorziehen.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Definitiv ja. Wenn z.B. größere Datenmengen via Submit an ein anderes Programm weitergereicht werden sollen und da durch den Submit eine neue LUW gestartet wird und sich anders ( als über die Übergabeparameter des gerufenen Programms ) keine Daten direkt übergeben lassen.4byte hat geschrieben:irgendwie finde ich den EXPORT TO MEMORY suspekt. Ich dachte immer man soll global gehaltene Daten vermeiden?
Gibt es jemanden, der das für seine (kunden)eigenen Porgramme verwendet ??
Geht auch umgekehrt ( und da verwende ich das auch gerne ) wenn man SAP-Standardprogramm aufruft um dann via Enhancementpoint direkt vor der Ausgabe die relevanten Daten mit EXPORT to MEMORY bereitzustellen und dann im aufrufenden Programm zu verwursteln.
Oder wenn z.B. via CALL TRANSACTION eine (SAP-Standard)Transaktion aufgerufen wird und hier speziell reagiert werden soll, wenn aus einem bestimmten Programm gerufen wurde.
Grundsätzlich mag ich die Variante immer dann wenn das aufgerufene Programm und das rufende Programm nichts voneinander sehen können aber ich mich nicht um (DB)Aufräumarbeiten kümmern möchte, wenn das (Haupt)Programm beendet wird
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Weh tut es auf jeden Fall, da Du damit immer die Feldkapselung durchbrichst. Eine Methode von Dir reicht auf einem undefinierten Weg ohne ordentliches Interface Werte an eine andere durch. Mit der Klasse baust Du Dir nur eine Krücke, um das später nachvollziehen zu können. Der nächste sieht nur den Befehl und weiß nicht, dass Du das in einer Klasse gekapselt hast und dass er mit solch Verwendungsnachweis weiterkommen würde. Und selbst wenn er darauf kommt, ist immer noch nicht klar, wer da an wen warum etwas weiterreicht.wenn man den export und den Import in einer Klasse kapselt, dann tut das überhaupt nicht weh.
Wie gesagt, es mag Rechtfertigungen geben, solch Krücke einzusetzen, aber weh tut es, und eine Krücke bleibt es.
Genau das, was man braucht um unzureichend definierte Exits von der SAP zu umgehen.DeathAndPain hat geschrieben:Weh tut es auf jeden Fall, da Du damit immer die Feldkapselung durchbrichst. Eine Methode von Dir reicht auf einem undefinierten Weg ohne ordentliches Interface Werte an eine andere durch.wenn man den export und den Import in einer Klasse kapselt, dann tut das überhaupt nicht weh.
Dann darf man ausnahmsweise auch ein bis zwei Kommentare dazu schreiben.DeathAndPain hat geschrieben:Mit der Klasse baust Du Dir nur eine Krücke, um das später nachvollziehen zu können. Der nächste sieht nur den Befehl und weiß nicht, dass Du das in einer Klasse gekapselt hast und dass er mit solch Verwendungsnachweis weiterkommen würde. Und selbst wenn er darauf kommt, ist immer noch nicht klar, wer da an wen warum etwas weiterreicht.
Zuletzt geändert von ewx am 19.04.2018 13:16, insgesamt 1-mal geändert.
Wenn ein Kundeneigener Report SAP Standard Methoden aufruft, welcher wiederum dynamisch kundeneigene Funktionsbausteine aufruft, dann geht es halt nicht anders, um Informationen an den Aufrufer zurückzuübermitteln.
Und genau für sowas ist das auch da.
Und genau für sowas ist das auch da.
Ja, das ist schon älter.DeathAndPain hat geschrieben:Ich halte das Ding für ein Relikt aus der Steinzeit.
Robin Hood war auch geächtet, ich mag IhnDeathAndPain hat geschrieben:Programmglobale Variablen sind ja schon weitgehend geächtet,
Memory ist nicht Systemglobal.DeathAndPain hat geschrieben:was soll man da erst von systemglobalen Variablen halten?
Das stimmt. Über Programme hinweg verwende ich das nur wennDeathAndPain hat geschrieben:Da holt sich ein Programm irgendwelche Daten aus dem Nirwana, und kein Schwein kann nachvollziehen, wer die da mal wann hinterlegt hat. Und nein, Dokumentation ist nicht die Antwort auf so einen Pfusch.
es nicht mit vertretbarem Aufwand anders geht.
Es gibt ja mittlerweile auch temporäre DB-Tabellen.black_adept hat geschrieben:Grundsätzlich mag ich die Variante immer dann wenn das aufgerufene Programm und das rufende Programm nichts voneinander sehen können aber ich mich nicht um (DB)Aufräumarbeiten kümmern möchte, wenn das (Haupt)Programm beendet wird
Da muss man nix mehr aufräumen.
Vergleichbare Themen
12
Antw.
Antw.
6738
Views
Views
8
Antw.
Antw.
3246
Views
Views
4
Antw.
Antw.
16905
Views
Views
8
Antw.
Antw.
7170
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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 3 Tagen von DeathAndPain 4 / 1415
vor 3 Tagen von DeathAndPain 4 / 1415
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 3 Tagen von DeathAndPain 4 / 1415
vor 3 Tagen von DeathAndPain 4 / 1415