Wir haben bei uns ein Tool entwickelt (ähnlich den Solution Manager, falls es der Vorstellungskraft dient ), indem viele Dynpros aufgerufen werden müssen.
Durch die gegebene Architektur haben wir ziemlich oft den Befehlt "Call Screen xxx" verwendet.
Wenn man etwas länger mit dem Tool herumspielt, kommt es dann zu einem Kurzdump, dass der Stack voll ist.
Ich habe bereits gegoogelt und leider nur Lösungen gefunden, die ich schwer in die Architektur einbringen kann:
1.
- Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)
- GeSHi ©
Das geht leider nicht so einfach in dem Programm. Da im Screen 0 einfach direkt wieder ein Dynpro aufgerufen wird. Ich habe den Umbau auch schon getestet. Leider zerschießt mir das ziemlich viel und man müsste viele Anpassungen vornehmen.
2.
- Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)
- CALL TRANSACTION
- GeSHi ©
Quelle:
[url]http://www.georgwiesinger.de/sap/daily-abap/daily-abap/archive/2010/february/article/kurzdump-list-too-many-lpros-die-zweite.html?tx_ttnews[day]=07&cHash=ce0ac6b7f5[/url].
Das wäre theoretisch möglich, allerdings dauert der Aufbau des Programms ca. 5 Sekunden, da viele Daten gepuffert werden und ein ALV TREE aufgebaut wird.
Ich habe mal nach FUBAs gesucht und bin sogar fündig geworden:
FUBA: STACK_RESET
Allerdings kann ich mir fast nicht vorstellen, dass es so einfach ist:
der Code ist nämlich nur:
- Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)
- function stack_reset.
- *"----------------------------------------------------------------------
- *"Lokale Schnittstelle:
- *"----------------------------------------------------------------------
- n-stack = 0.
- GeSHi ©
Der Verwendungsnachweis ist ziemlich düftig:
Wenn ich Mal Kommentare finde, sehen die so aus:
"Baut den internen Stack der Folgebildsteuerung ab."
Das ist doch eigentlich genau das was ich brauche oder sehe ich das falsch?
Hat vielleicht jemand schonmal dasselbe Problem gehabt und eine Lösung parat
Vielen Dank schonmal und Gruß,
Henrik