interne Tabelle übergeben von Report zu Report
Hallo Zuasammen,
ich möchte eine interne Tabelle von einem Report zu anderem Report über geben. Leider hat es nicht geklappt bei mir. Folgendes ist meine Coding:
REPORT ZTEST1.
DATA: gt_sflight_e TYPE TABLE OF sflight,
gt_sflight LIKE gt_sflight_e.
START-OF-SELECTION.
SELECT * FROM sflight INTO CORRESPONDING FIELDS OF TABLE gt_sflight_e.
EXPORT gt_sflight FROM gt_sflight_e TO MEMORY ID 'CTAB'.
SUBMIT ZTEST2.
==================================
REPORT ZTEST2.
DATA: gt_sflight_i TYPE TABLE OF sflight,
gt_sflight LIKE gt_sflight_i.
START-OF-SELECTION.
IMPORT gt_sflight TO gt_sflight_i FROM MEMORY ID 'CTAB'.
======
Ich habe debuggert bei dem Programm ZTEST1 und habe gesehen bei der Anweisung EXPORT gt_sflight FROM gt_sflight_e TO MEMORY ID 'CTAB' die interne Tabelle gt_sflight war leer, dh die Daten von der Tabelle gt_sflight_e wurden nicht zur internen Tabelle gt_sflight übergegeben. Habe ich Fehler gemacht? Was ist ID hier gemeint? Kann man irgendeine ID ausdenken, nur Hauptsache bei IMPORT und EXPORT muss gleiche ID sein?
Vielen Dank für jede Antwort.
cuncon
ich möchte eine interne Tabelle von einem Report zu anderem Report über geben. Leider hat es nicht geklappt bei mir. Folgendes ist meine Coding:
REPORT ZTEST1.
DATA: gt_sflight_e TYPE TABLE OF sflight,
gt_sflight LIKE gt_sflight_e.
START-OF-SELECTION.
SELECT * FROM sflight INTO CORRESPONDING FIELDS OF TABLE gt_sflight_e.
EXPORT gt_sflight FROM gt_sflight_e TO MEMORY ID 'CTAB'.
SUBMIT ZTEST2.
==================================
REPORT ZTEST2.
DATA: gt_sflight_i TYPE TABLE OF sflight,
gt_sflight LIKE gt_sflight_i.
START-OF-SELECTION.
IMPORT gt_sflight TO gt_sflight_i FROM MEMORY ID 'CTAB'.
======
Ich habe debuggert bei dem Programm ZTEST1 und habe gesehen bei der Anweisung EXPORT gt_sflight FROM gt_sflight_e TO MEMORY ID 'CTAB' die interne Tabelle gt_sflight war leer, dh die Daten von der Tabelle gt_sflight_e wurden nicht zur internen Tabelle gt_sflight übergegeben. Habe ich Fehler gemacht? Was ist ID hier gemeint? Kann man irgendeine ID ausdenken, nur Hauptsache bei IMPORT und EXPORT muss gleiche ID sein?
Vielen Dank für jede Antwort.
cuncon
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Moin.
bei mir ist gt_sflight_i in Ztest2 gefüllt.
Man sollte eine ID verwenden , die nicht anderweitig benutzt wird. (z.B. Sy-repid)
es geht auch so:
siehe auch https://www.berater-wiki.de/Schl%C3%BCs ... rom_memory
gruß Jens
bei mir ist gt_sflight_i in Ztest2 gefüllt.
Man sollte eine ID verwenden , die nicht anderweitig benutzt wird. (z.B. Sy-repid)
es geht auch so:
Code: Alles auswählen.
REPORT ZTEST_MEMORY1.
DATA: gt_sfl TYPE TABLE OF sflight.
SELECT * FROM sflight INTO CORRESPONDING FIELDS OF TABLE gt_sfl.
EXPORT gt_sfl FROM gt_sfl TO MEMORY ID 'CTAB'.
SUBMIT ZTEST_MEMORY2.Code: Alles auswählen.
REPORT ZTEST_MEMORY2.
DATA: gt_sfl TYPE TABLE OF sflight.
IMPORT gt_sfl TO gt_sfl FROM MEMORY ID 'CTAB'.
siehe auch https://www.berater-wiki.de/Schl%C3%BCs ... rom_memory
gruß Jens
Zuletzt geändert von Tron am 26.10.2017 13:12, insgesamt 1-mal geändert.
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Wenn es um eigene Entwicklungen geht ist die Übergabe
durch Memory nicht empfehlenswert. Besser ist es im
gerufenen Programm eine Form-Routine mit entsprechenden
Parametern aufzurufen.
durch Memory nicht empfehlenswert. Besser ist es im
gerufenen Programm eine Form-Routine mit entsprechenden
Parametern aufzurufen.
Folgende Benutzer bedankten sich beim Autor Daniel für den Beitrag (Insgesamt 2):
cuncon • DeathAndPain
Hi Jens,Tron hat geschrieben:Moin.
bei mir ist gt_sflight_i in Ztest2 gefüllt.
Man sollte eine ID verwenden , die nicht anderweitig benutzt wird. (z.B. Sy-repid)
es geht auch so:Code: Alles auswählen.
REPORT ZTEST_MEMORY1. DATA: gt_sfl TYPE TABLE OF sflight. SELECT * FROM sflight INTO CORRESPONDING FIELDS OF TABLE gt_sfl. EXPORT gt_sfl FROM gt_sfl TO MEMORY ID 'CTAB'. SUBMIT ZTEST_MEMORY2.Code: Alles auswählen.
REPORT ZTEST_MEMORY2. DATA: gt_sfl TYPE TABLE OF sflight. IMPORT gt_sfl TO gt_sfl FROM MEMORY ID 'CTAB'.
siehe auch https://www.berater-wiki.de/Schl%C3%BCs ... rom_memory
gruß Jens
Vielen dank für die schnelle Antwort. Du hast recht. Ich sehe jetzt die Tabelle gt_sflight_i gefüllt
. Dann ist die Sache ist erledigt.Daniel hat geschrieben:Wenn es um eigene Entwicklungen geht ist die Übergabe
durch Memory nicht empfehlenswert. Besser ist es im
gerufenen Programm eine Form-Routine mit entsprechenden
Parametern aufzurufen.
wie hast du damit gemeint? Wenn ich die Methode durch Memory nicht nutze, wie kann ich die interne Tabelle von einem Programm zu anderem Programm übertragen?
cuncon
Beitrag
von black_adept (Top Expert / 4086 / 126 /
940
)
»
@Daniel: Bei SUBMIT wird aber ein neuer Rollbereich aufgemacht, so dass die Callbackroutine nicht auf die Daten des 1. Reports mehr zugreifen kann bzw. wenn die Daten in einem globalen Feld liegen dieses dann leer ist.
Kein Submit sondern
Die Form steuert dann den Programmfluss im gerufenen
Programm.
Code: Alles auswählen.
PERFORM called IN PROGRAM zprog
TABLES x
USING y
CHANGING z.
Programm.
Beitrag
von black_adept (Top Expert / 4086 / 126 /
940
)
»
Ah - du willst das so rum machen. Das ist natürlich auch ein gangbarer Weg
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Wobei das auch nicht das trifft, was er gemeint hat. Mal abgesehen davon, dass der Aufruf von Formroutinen anderer Programme als massiv obsolet gilt (freilich auch nicht schlimmer als das Verstecken von Daten im Nirwana per EXPORT TO MEMORY), war sein Wunsch doch, dass der ganze Zielreport aufgerufen wird, also komplett mit Selektions- und Ergebnisbild. Ein PERFORM kann das nicht leisten.
Was ich an der Stelle empfehlen würde (und was ich auch stilistisch für bedeutend sauberer halte als beide vorgenannten Ansätze), ist das Ausstatten des gerufenen Reports mit passenden SELECT-OPTIONS. Dann kann man im SUBMIT-Befehl die Tabelleninhalte (passend in RANGES-Tabellen verpackt) übergeben und hat eine klare, vernünftig nachvollziehbare Schnittstelle. Wenn der gerufene Report auch händisch nutzbar sein soll und man Angst hat, sich das Selektionsbild mit haufenweise SELECT-OPTIONS zuzumüllen, die es unübersichtlich machen und die bei manueller Ausführung nicht gebraucht werden, so steht es einem frei, diese mit dem Zusatz NO-DISPLAY zu definieren.
Was ich an der Stelle empfehlen würde (und was ich auch stilistisch für bedeutend sauberer halte als beide vorgenannten Ansätze), ist das Ausstatten des gerufenen Reports mit passenden SELECT-OPTIONS. Dann kann man im SUBMIT-Befehl die Tabelleninhalte (passend in RANGES-Tabellen verpackt) übergeben und hat eine klare, vernünftig nachvollziehbare Schnittstelle. Wenn der gerufene Report auch händisch nutzbar sein soll und man Angst hat, sich das Selektionsbild mit haufenweise SELECT-OPTIONS zuzumüllen, die es unübersichtlich machen und die bei manueller Ausführung nicht gebraucht werden, so steht es einem frei, diese mit dem Zusatz NO-DISPLAY zu definieren.
Beitrag
von black_adept (Top Expert / 4086 / 126 /
940
)
»
Die Vorgehensweise halte ich für übermäßig kompliziert, die Serialisierung und Deserialisierung der Daten muss auch noch gemacht werden und wenn der User auf die glorreiche Idee kommt eine Variante zu speichern, bei der große! Mengen an Daten im Selektionsbild versteckt sind dürfte das System darüber alles andere als glücklich sein.
SAP hat doch das Import und Export to Memory gerade für diese Fälle vorgesehen. Was die nachvollziehbare Schnittstelle angeht, so würde ich stattdessen lieber ein unsichtbares Feld auf dem SelScreen platzieren, wo ich die Memory-ID hinterlegen kann mit der die Daten aus dem Memory gefischt werden können. Wenn man das dann noch wie in dem Beitrag von Enno macht, indem man die MemoryID als Attribut einer Klasse definiert bekommt man dann sogar einen schönen Verwendungsnachweis.
SAP hat doch das Import und Export to Memory gerade für diese Fälle vorgesehen. Was die nachvollziehbare Schnittstelle angeht, so würde ich stattdessen lieber ein unsichtbares Feld auf dem SelScreen platzieren, wo ich die Memory-ID hinterlegen kann mit der die Daten aus dem Memory gefischt werden können. Wenn man das dann noch wie in dem Beitrag von Enno macht, indem man die MemoryID als Attribut einer Klasse definiert bekommt man dann sogar einen schönen Verwendungsnachweis.
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Das sehe ich anders. Aus meiner Sicht ist das MEMORY ein nur aus Kompatibilitätsgründen noch vorhandenes Relikt längst vergangener Zeiten, das in modernen Programmen nichts zu suchen hat.
Bei wenigen Spalten kein Problem, und bei vielen Spalten halte ich es für einen Designfehler, einen Report damit füttern zu wollen. Da liegt dann im generellen Konzept was im Argen. Wahrscheinlich braucht man dann gar keinen separaten Report, sondern doch nur eine Unterroutine (PERFORM) oder gar einen Funktionsbaustein oder Modulpool.die Serialisierung und Deserialisierung der Daten muss auch noch gemacht werden
Wie soll das passieren, wenn der Zielreport nur vom Quellreport aufgerufen wird und/oder die betreffenden Selektionsparameter mit NO DISPLAY definiert sind?und wenn der User auf die glorreiche Idee kommt eine Variante zu speichern, bei der große! Mengen an Daten im Selektionsbild versteckt sind
Was irgendwelche Leute für obsolet halten ist mir so einerleiDeathAndPain hat geschrieben:Mal abgesehen davon, dass der Aufruf von Formroutinen anderer Programme als massiv obsolet gilt
wie die Geistergeschichten die der Papst verbreitet.
Es kommt darauf an daß es zuverlässig funktioniert und gut
nachvollziehbar ist.
Das geht auch mit einem Perform. Wenn wirklich viele Daten zu übergebenDeathAndPain hat geschrieben:war sein Wunsch doch, dass der ganze Zielreport aufgerufen wird, also komplett mit Selektions- und Ergebnisbild. Ein PERFORM kann das nicht leisten.
sind ist normalerweise ein Selektionsbild gerade nicht erforderlich.
Bei wenigen Daten ist die Version mit SELECT-OPTIONS allerdings zielführend.
Da ist was dran. Wenn die in einem anderen Report bereits fertigDeathAndPain hat geschrieben:Bei wenigen Spalten kein Problem, und bei vielen Spalten halte ich es für einen Designfehler, einen Report damit füttern zu wollen. Da liegt dann im generellen Konzept was im Argen. Wahrscheinlich braucht man dann gar keinen separaten Report, sondern doch nur eine Unterroutine (PERFORM) oder gar einen Funktionsbaustein oder Modulpool.
vorliegt würde ich die aber auch nicht kopieren. Evtl. per Include
in beiden Reports verfügbar machen. Kommt auf die Komplexität
der gebrauchten Funktion an.
Beitrag
von ralf.wenzel (Top Expert / 3921 / 200 /
280
)
»
Da gibt es Meinungen wie es Entwickler gibt, ich z. B. halte nichts von der Mehrfachverwendung von Includes. Da kann man das Coding auch gleich kopieren (nichts anderes macht ABAP beim Aktivieren). Man erhöht nur die Abhängigkeiten, es ist ja bekannt, dass ich ein Freund von in sich geschlossenen Modulen bin. Das erleichtert einfach die Wartung wenn ich weiß, dass ich jetzt nur das ändere, was ich sehe und nicht noch x Programme, die das inkludiert haben. Darum rät auch die SAP davon ab.
Die Vielfalt der Meinungen hilft dem Fragenden aber nicht
Ralf
Die Vielfalt der Meinungen hilft dem Fragenden aber nicht
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Man kann das halt nicht pauschal beantworten.
Es kommt immer auf die Aufgabenstellung und
darauf an was bereits vorhanden ist.
Es kommt immer auf die Aufgabenstellung und
darauf an was bereits vorhanden ist.
Folgende Benutzer bedankten sich beim Autor Daniel für den Beitrag:
DeathAndPain
Vergleichbare Themen
0
Antw.
Antw.
1475
Views
Views
Tabelle übergeben von Report an BSP
von herr mb » 18.06.2014 10:17 • Verfasst in Web-Dynpro, BSP + BHTML
von herr mb » 18.06.2014 10:17 • Verfasst in Web-Dynpro, BSP + BHTML
5
Antw.
Antw.
2080
Views
Views
Inhalt interne Tabelle an andere interne Tabelle übergeben
von L0w-RiDer » 30.01.2020 16:28 • Verfasst in ABAP® für Anfänger
von L0w-RiDer » 30.01.2020 16:28 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
3669
Views
Views
Report von einem anderen Report als Hintergrundjob einplanen
von kbit100 » 04.01.2016 09:46 • Verfasst in ABAP® für Anfänger
von kbit100 » 04.01.2016 09:46 • Verfasst in ABAP® für Anfänger
0
Antw.
Antw.
2931
Views
Views
19
Antw.
Antw.
8563
Views
Views
Feedback-->Aufruf z-report ein SAP Standard Report
von c oco » 06.02.2013 16:55 • Verfasst in ABAP® für Anfänger
von c oco » 06.02.2013 16:55 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
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 26 Minuten von DeathAndPain 4 / 444
vor 26 Minuten von DeathAndPain 4 / 444
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 26 Minuten von DeathAndPain 4 / 444
vor 26 Minuten von DeathAndPain 4 / 444