GUI_UPLOAD, dp_out_of_memory
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo zusammen,
ich habe im Forum nach einem ähnlichen Problem gesucht, aber leider keinen Thread gefunden.
Ich verwende in einem Report den GUI_UPLOAD und erhalte bei einer sehr großen Textdatei den Fehler (14) dp_out_of_memory. Das passiert allerdings erst auf dem Konsolidierungssystem. Die gleiche Datei ließ sich auf dem Entwicklungssystem problemlos hochladen. Ich vermute also laienhaft, dass es am System liegt, bin mir aber nicht so sicher. Kennt jemand das Problem und wie man sich behelfen kann? Anbei mein Coding:
Vielen Dank für eure Hilfe.
Gruß
K.
ich habe im Forum nach einem ähnlichen Problem gesucht, aber leider keinen Thread gefunden.
Ich verwende in einem Report den GUI_UPLOAD und erhalte bei einer sehr großen Textdatei den Fehler (14) dp_out_of_memory. Das passiert allerdings erst auf dem Konsolidierungssystem. Die gleiche Datei ließ sich auf dem Entwicklungssystem problemlos hochladen. Ich vermute also laienhaft, dass es am System liegt, bin mir aber nicht so sicher. Kennt jemand das Problem und wie man sich behelfen kann? Anbei mein Coding:
Code: Alles auswählen.
CALL METHOD cl_gui_frontend_services=>gui_upload
EXPORTING
filename = lv_quelldatei
CHANGING
data_tab = lt_dateiinhalt
EXCEPTIONS
file_open_error = 1
file_read_error = 2
no_batch = 3
gui_refuse_filetransfer = 4
invalid_type = 5
no_authority = 6
unknown_error = 7
bad_data_format = 8
header_not_allowed = 9
separator_not_allowed = 10
header_too_long = 11
unknown_dp_error = 12
access_denied = 13
dp_out_of_memory = 14
disk_full = 15
dp_timeout = 16
not_supported_by_gui = 17
error_no_gui = 18
OTHERS = 19.
IF sy-subrc <> 0.
MESSAGE ID 'ZEBI_MESS1' TYPE 'E' NUMBER '145' WITH sy-subrc lv_quelldatei .
ENDIF.
Gruß
K.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Das kann gar nicht sein, dass du den Fehler bekommst!
Der ist currently not used.
http://help.sap.com/saphelp_nw70ehp2/he ... ontent.htm
Wahrscheinlich könnte die Änderung eines Systemparameters helfen. Aber welcher? Keine Ahnung.
Ich hätte aber einen veralteten Workaround mit WS_UPLOAD anzubieten.
Hier werden die Daten zeilenweise gelesen und können dementsprechend einzeln verarbeitet werden.
Ist vielleicht eine gute Idee bei einer so großen Datenmenge?
Der ist currently not used.
http://help.sap.com/saphelp_nw70ehp2/he ... ontent.htm
Wahrscheinlich könnte die Änderung eines Systemparameters helfen. Aber welcher? Keine Ahnung.
Ich hätte aber einen veralteten Workaround mit WS_UPLOAD anzubieten.
Hier werden die Daten zeilenweise gelesen und können dementsprechend einzeln verarbeitet werden.
Ist vielleicht eine gute Idee bei einer so großen Datenmenge?
Code: Alles auswählen.
DATA gt_data TYPE STANDARD TABLE OF string.
CALL FUNCTION 'WS_UPLOAD'
EXPORTING
filename = 'c:\Users\ewulff\Documents\test.txt'
filetype = 'ASC'
line_exit = 'USER'
user_form = 'CALLBACK_UPLOAD'
user_prog = sy-cprog
TABLES
data_tab = gt_data
EXCEPTIONS
conversion_error = 1
file_open_error = 2
file_read_error = 3
invalid_type = 4
no_batch = 5
unknown_error = 6
invalid_table_width = 7
gui_refuse_filetransfer = 8
customer_error = 9
no_authority = 10
OTHERS = 11.
IF sy-subrc > 0.
WRITE: 'Fehler:', sy-subrc.
ENDIF.
*&---------------------------------------------------------------------*
*& Form callback_upload
*&---------------------------------------------------------------------*
FORM callback_upload USING text.
WRITE: / text.
ENDFORM. "callback_uploadNormalerweise sind die erlaubten Speichergrößen in einem Konsolidierungssystem höher als in einem Entwicklungssystem. Das kannst du ja mal prüfen. Die entsprechenden Profilparameter findest du im Dump und kannst sie mit dem Report RSPARAM anzeigen lassen.
Kann es sein, dass du zuvor in deinem Programm noch andere Dinge machst, die Speicher verbrauchen.
z.B. Daten lesen und interne Tabellen befüllen oder Funktionsbausteine aufrufen, die ggf. Speicher belegen.
Da die Datenbestände im Entwicklungssystem in der Regel viel kleiner sind als im Konsolidierungssystem, könnte das eine mögliche Ursache sein.
Kann es sein, dass du zuvor in deinem Programm noch andere Dinge machst, die Speicher verbrauchen.
z.B. Daten lesen und interne Tabellen befüllen oder Funktionsbausteine aufrufen, die ggf. Speicher belegen.
Da die Datenbestände im Entwicklungssystem in der Regel viel kleiner sind als im Konsolidierungssystem, könnte das eine mögliche Ursache sein.
Vielen Dank für den Tipp.
Allerdings weiß ich leider nicht, worauf ich bei der Ausgabe des Reports RSPARAM wirklich achten muss. Ich tippe mal auf die Angabe EM/TOTAL_SIZE_MB, die beim Konsolidierungssystem größer ist.
Der geschilderte Fehler trat zuerst im Konsolidierungssystem nicht auf. Erst als das Zielverzeichnis geändert wurde, kam es zum Fehler. Es wurde immer nur dieses eine Programm gestartet, was auch so im Entwicklungssystem problemlos funktioniert. Andere Verarbeitungen fanden nicht statt.
Allerdings weiß ich leider nicht, worauf ich bei der Ausgabe des Reports RSPARAM wirklich achten muss. Ich tippe mal auf die Angabe EM/TOTAL_SIZE_MB, die beim Konsolidierungssystem größer ist.
Der geschilderte Fehler trat zuerst im Konsolidierungssystem nicht auf. Erst als das Zielverzeichnis geändert wurde, kam es zum Fehler. Es wurde immer nur dieses eine Programm gestartet, was auch so im Entwicklungssystem problemlos funktioniert. Andere Verarbeitungen fanden nicht statt.
Wenn es sich um ein Speicherproblem des Applikationsservers handelt und ein Dump erzeugt wird, dann sollten die entsprechenden Profilparameter im Dump genannt werden.
Mir ist gerade noch etwas eingefallen. Es könnte sich auch um ein PC-Problem handeln. Kannst du das ganze mal an einem anderen PC mit ggf. mehr Speicher ausführen.
Mir ist gerade noch etwas eingefallen. Es könnte sich auch um ein PC-Problem handeln. Kannst du das ganze mal an einem anderen PC mit ggf. mehr Speicher ausführen.
Vielen Dank an alle Tippgeber!
Leider gab es keine Lösung in meinem Fall. Es half nur ein Splitten der Datei in mehrere Einzelsegmente, die dann hochgeladen wurden. Der WS_UPLOAD war keine Option, weil das von der Qualitätskontrolle nicht abgenickt worden wäre, da der Fuba obsolet sei.
Leider gab es keine Lösung in meinem Fall. Es half nur ein Splitten der Datei in mehrere Einzelsegmente, die dann hochgeladen wurden. Der WS_UPLOAD war keine Option, weil das von der Qualitätskontrolle nicht abgenickt worden wäre, da der Fuba obsolet sei.
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
Wenn der WS_UPLOAD das Problem lösen würde, kannst du ihn ja auf Z_WS_UPLOAD kopieren. Dann ist die Qualitätskontrolle zufrieden und du auch.
Seite 1 von 1
Vergleichbare Themen
21
Antw.
Antw.
4457
Views
Views
8
Antw.
Antw.
6805
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.