Dump - Cursor bereits geschlossenen oder noch nicht geöffnet
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo zusammen,
ich rufe einen RFC fähigen Kunden Fuba in einem anderen SAP Zielsystem auf.
im Dialog kommt es zum Abbruch mit folgender Fehlermeldung
Laufzeitfehler DBSQL_INVALID_CURSOR
Ausnahme CX_SY_OPEN_SQL_DB
Wenn ich im Hintergrund die Anwendung starte, läuft es problemlos durch und die Prüfung auf dem Zielsystem erfolgt und ich erhalte das erwartete Ergebnis.
Ich vermute, dass ein RFC einen impliziten Commit absetzt und der Cursor dadurch geschlossen wird.
Folgende Szenarien führen nicht zum Erfolg:
CALL FUNCTION 'ZFUBA' DESTINATION lv_dest => Dump im Dialog und gewünschtes Ergebnis im Hintergrundlauf
CALL FUNCTION 'ZFUBA' in BACKGROUND TASK DESTINATION lv_dest => läuft im Dialog ohne Dump, aber der Fuba im Zielsystem wird nicht durchlaufen und das Ergebnis wird nicht geliefert.
CALL FUNCTION 'ZFUBA' STARTING NEW TASK 'NEW' DESTINATION lv_dest => Dump im Dialog
Habt ihr eine Idee was ich noch probieren könnte oder ähnliche Erfahrungen gemacht?
Anbei die Fehlerbeschreibung:
Fehleranalyse
Es ist eine Ausnahme aufgetreten, die weiter unten näher erläutert wird.
Die Ausnahme, der die Klasse 'CX_SY_OPEN_SQL_DB' zugeordnet ist,
wurde in der Prozedur "MAIN_LOOP" "(FORM)" weder abgefangen,
noch durch eine RAISING-Klausel propagiert.
Da der Aufrufer der Prozedur nicht mit dem Auftreten der Ausnahme
rechnen konnte, wurde das laufende Programm abgebrochen.
Der Grund für die Ausnahme ist:
Der bei einem FETCH- oder CLOSE CURSOR-Befehl benutzte Cursor ist
nicht offen. Entweder wurde er noch nicht geöffnet oder er wurde
bereits geschlossen. Das Schließen des Cursors kann explizit durch
den Befehl CLOSE CURSOR oder implizit durch den Befehl COMMIT WORK
oder durch einen Bildwechsel erfolgt sein.
Gruß
coco
ich rufe einen RFC fähigen Kunden Fuba in einem anderen SAP Zielsystem auf.
im Dialog kommt es zum Abbruch mit folgender Fehlermeldung
Laufzeitfehler DBSQL_INVALID_CURSOR
Ausnahme CX_SY_OPEN_SQL_DB
Wenn ich im Hintergrund die Anwendung starte, läuft es problemlos durch und die Prüfung auf dem Zielsystem erfolgt und ich erhalte das erwartete Ergebnis.
Ich vermute, dass ein RFC einen impliziten Commit absetzt und der Cursor dadurch geschlossen wird.
Folgende Szenarien führen nicht zum Erfolg:
CALL FUNCTION 'ZFUBA' DESTINATION lv_dest => Dump im Dialog und gewünschtes Ergebnis im Hintergrundlauf
CALL FUNCTION 'ZFUBA' in BACKGROUND TASK DESTINATION lv_dest => läuft im Dialog ohne Dump, aber der Fuba im Zielsystem wird nicht durchlaufen und das Ergebnis wird nicht geliefert.
CALL FUNCTION 'ZFUBA' STARTING NEW TASK 'NEW' DESTINATION lv_dest => Dump im Dialog
Habt ihr eine Idee was ich noch probieren könnte oder ähnliche Erfahrungen gemacht?
Anbei die Fehlerbeschreibung:
Fehleranalyse
Es ist eine Ausnahme aufgetreten, die weiter unten näher erläutert wird.
Die Ausnahme, der die Klasse 'CX_SY_OPEN_SQL_DB' zugeordnet ist,
wurde in der Prozedur "MAIN_LOOP" "(FORM)" weder abgefangen,
noch durch eine RAISING-Klausel propagiert.
Da der Aufrufer der Prozedur nicht mit dem Auftreten der Ausnahme
rechnen konnte, wurde das laufende Programm abgebrochen.
Der Grund für die Ausnahme ist:
Der bei einem FETCH- oder CLOSE CURSOR-Befehl benutzte Cursor ist
nicht offen. Entweder wurde er noch nicht geöffnet oder er wurde
bereits geschlossen. Das Schließen des Cursors kann explizit durch
den Befehl CLOSE CURSOR oder implizit durch den Befehl COMMIT WORK
oder durch einen Bildwechsel erfolgt sein.
Gruß
coco
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Wo ist der "MAIN_LOOP" beheimatet bzw. wo entsteht der Kurzdump?
Im Zielsystem oder im Aufrufersystem?
Du hast schon recht, dass ein CALL FUNCTION ein implizites Commit absetzt. Er muss ja die aktuelle Verarbeitung pausieren (damit die Ressourcen für andere frei sind) und auf den anderen Server wechseln.
Von daher würde ich darauf tippen, dass der Fehler in deinem Aufrufersystem auftritt und nichts mit dem RFC im Zielsystem zu tun hat. Da du schreibst, dass es im Hintergrund problemlos funktioniert, dürfte der Fehler mit dem GUI selbst zu tun haben. Also am ehesten mit einem GUI-Control, weil nur diese eine "aktive" Rolle in der Kommunikation haben. Viele GUI Controls haben einen off-switch wenn kein GUI vorhanden ist (wie z.B. in einem Job). Kann es sein, dass du den RFC z.b. nach einer Auswahl in einem ALV-Grid oder ähnlichem machst, während beim Aufruf im Hintergrundjob keine Auswahl erfolgt und einfach alle Einträge durchlaufen werden?
in BACKGROUND TASK liefert übrigens keine Ergebnisse weil dafür vermutlich die RFC-Verbindung noch nicht korrekt eingerichtet wurde (mit Rückkanal-RFC). Mehr dazu in der ABAP bzw. SAP-Hilfe. Aber auch hier würde im Online-Aufruf vermutlich ein Kurzdump kommen, weil auch hier die Vearbeitung "pausieren" muss.
In STARTING NEW TASK sollte es eigentlich funktionieren, weil da kein pausieren des aktuellen Prozesses nötig ist und somit auch kein implizites Commit. Vermutlich ist der Fehler hier etwas anders gelagert und du nimmst nur an, dass es derselbe Fehler ist.
Kleiner TIPP:
Bei CALL FUNCTION ... DESTINATION immer die beiden Standard-Exceptions SYSTEM_FAILURE und COMMUNCATION_FAILURE mit dem MESSAGE-Zusatz ausprogrammieren. Da kriegt man oft noch sehr interessante Informationen mitgeschickt die vielleicht mehr helfen als ein Kurzdump (sofern dieser überhaupt geschrieben wird, was ich auch schon mal hatte)
EDIT:
CX_SY_OPEN_SQL_DB ... hmmm ... rufst du den RFC innerhalb eines SELECT ... ENDSELECT oder OPEN CURSOR ... CLOSE CURSOR auf? Dann sollte aber auch im Hintergrund ein Fehler kommen. Oder läuft irgendeine Art von (BAL)-Logging in eurem System das Benutzeraktivitäten aufzeichnen soll?
Im Zielsystem oder im Aufrufersystem?
Du hast schon recht, dass ein CALL FUNCTION ein implizites Commit absetzt. Er muss ja die aktuelle Verarbeitung pausieren (damit die Ressourcen für andere frei sind) und auf den anderen Server wechseln.
Von daher würde ich darauf tippen, dass der Fehler in deinem Aufrufersystem auftritt und nichts mit dem RFC im Zielsystem zu tun hat. Da du schreibst, dass es im Hintergrund problemlos funktioniert, dürfte der Fehler mit dem GUI selbst zu tun haben. Also am ehesten mit einem GUI-Control, weil nur diese eine "aktive" Rolle in der Kommunikation haben. Viele GUI Controls haben einen off-switch wenn kein GUI vorhanden ist (wie z.B. in einem Job). Kann es sein, dass du den RFC z.b. nach einer Auswahl in einem ALV-Grid oder ähnlichem machst, während beim Aufruf im Hintergrundjob keine Auswahl erfolgt und einfach alle Einträge durchlaufen werden?
in BACKGROUND TASK liefert übrigens keine Ergebnisse weil dafür vermutlich die RFC-Verbindung noch nicht korrekt eingerichtet wurde (mit Rückkanal-RFC). Mehr dazu in der ABAP bzw. SAP-Hilfe. Aber auch hier würde im Online-Aufruf vermutlich ein Kurzdump kommen, weil auch hier die Vearbeitung "pausieren" muss.
In STARTING NEW TASK sollte es eigentlich funktionieren, weil da kein pausieren des aktuellen Prozesses nötig ist und somit auch kein implizites Commit. Vermutlich ist der Fehler hier etwas anders gelagert und du nimmst nur an, dass es derselbe Fehler ist.
Kleiner TIPP:
Bei CALL FUNCTION ... DESTINATION immer die beiden Standard-Exceptions SYSTEM_FAILURE und COMMUNCATION_FAILURE mit dem MESSAGE-Zusatz ausprogrammieren. Da kriegt man oft noch sehr interessante Informationen mitgeschickt die vielleicht mehr helfen als ein Kurzdump (sofern dieser überhaupt geschrieben wird, was ich auch schon mal hatte)
EDIT:
CX_SY_OPEN_SQL_DB ... hmmm ... rufst du den RFC innerhalb eines SELECT ... ENDSELECT oder OPEN CURSOR ... CLOSE CURSOR auf? Dann sollte aber auch im Hintergrund ein Fehler kommen. Oder läuft irgendeine Art von (BAL)-Logging in eurem System das Benutzeraktivitäten aufzeichnen soll?
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo ADT,
danke für deine Antwort.
Du hast schon recht, dass ein CALL FUNCTION ein implizites Commit absetzt. Er muss ja die aktuelle Verarbeitung pausieren (damit die Ressourcen für andere frei sind) und auf den anderen Server wechseln.
Von daher würde ich darauf tippen, dass der Fehler in deinem Aufrufersystem auftritt und nichts mit dem RFC im Zielsystem zu tun hat. Da du schreibst, dass es im Hintergrund problemlos funktioniert, dürfte der Fehler mit dem GUI selbst zu tun haben. Also am ehesten mit einem GUI-Control, weil nur diese eine "aktive" Rolle in der Kommunikation haben. Viele GUI Controls haben einen off-switch wenn kein GUI vorhanden ist (wie z.B. in einem Job).
in BACKGROUND TASK liefert übrigens keine Ergebnisse weil dafür vermutlich die RFC-Verbindung noch nicht korrekt eingerichtet wurde (mit Rückkanal-RFC). Mehr dazu in der ABAP bzw. SAP-Hilfe. Aber auch hier würde im Online-Aufruf vermutlich ein Kurzdump kommen, weil auch hier die Vearbeitung "pausieren" muss.
Gruss
Coco
danke für deine Antwort.
im Aufrufersystema-dead-trousers hat geschrieben: ↑20.07.2022 10:13Wo ist der "MAIN_LOOP" beheimatet bzw. wo entsteht der Kurzdump?
Im Zielsystem oder im Aufrufersystem?
Du hast schon recht, dass ein CALL FUNCTION ein implizites Commit absetzt. Er muss ja die aktuelle Verarbeitung pausieren (damit die Ressourcen für andere frei sind) und auf den anderen Server wechseln.
Von daher würde ich darauf tippen, dass der Fehler in deinem Aufrufersystem auftritt und nichts mit dem RFC im Zielsystem zu tun hat. Da du schreibst, dass es im Hintergrund problemlos funktioniert, dürfte der Fehler mit dem GUI selbst zu tun haben. Also am ehesten mit einem GUI-Control, weil nur diese eine "aktive" Rolle in der Kommunikation haben. Viele GUI Controls haben einen off-switch wenn kein GUI vorhanden ist (wie z.B. in einem Job).
Nein, kein ALV-Grid.a-dead-trousers hat geschrieben: ↑20.07.2022 10:13Kann es sein, dass du den RFC z.b. nach einer Auswahl in einem ALV-Grid oder ähnlichem machst, während beim Aufruf im Hintergrundjob keine Auswahl erfolgt und einfach alle Einträge durchlaufen werden?
in BACKGROUND TASK liefert übrigens keine Ergebnisse weil dafür vermutlich die RFC-Verbindung noch nicht korrekt eingerichtet wurde (mit Rückkanal-RFC). Mehr dazu in der ABAP bzw. SAP-Hilfe. Aber auch hier würde im Online-Aufruf vermutlich ein Kurzdump kommen, weil auch hier die Vearbeitung "pausieren" muss.
das hat mich auch gewundert, weil ich damit gerechnet habe, dass es damit zu lösen sein sollte. Kann sein, dass es wo anders gelagert ist, für mich ist es nicht erkennbar, da der selbe Laufzeitfehler, und im Dubugger läuft die Zielverarbeitung in einem neuen Task während der andere Task wartet.a-dead-trousers hat geschrieben: ↑20.07.2022 10:13In STARTING NEW TASK sollte es eigentlich funktionieren, weil da kein pausieren des aktuellen Prozesses nötig ist und somit auch kein implizites Commit. Vermutlich ist der Fehler hier etwas anders gelagert und du nimmst nur an, dass es derselbe Fehler ist.
Danke für den Tipp. Habe ich jetzt übernommen.a-dead-trousers hat geschrieben: ↑20.07.2022 10:13Kleiner TIPP:
Bei CALL FUNCTION ... DESTINATION immer die beiden Standard-Exceptions SYSTEM_FAILURE und COMMUNCATION_FAILURE mit dem MESSAGE-Zusatz ausprogrammieren. Da kriegt man oft noch sehr interessante Informationen mitgeschickt die vielleicht mehr helfen als ein Kurzdump (sofern dieser überhaupt geschrieben wird, was ich auch schon mal hatte)
ich mache vor dem RFC Aufruf einen Select Single. Jedoch auch wenn ich den Select rausnehme, kommt der Dump. (BAL)-Logging in eurem System das Benutzeraktivitäten aufzeichnen soll? Das weiß ich nicht, wie kann ich das rausfinden?a-dead-trousers hat geschrieben: ↑20.07.2022 10:13EDIT:
CX_SY_OPEN_SQL_DB ... hmmm ... rufst du den RFC innerhalb eines SELECT ... ENDSELECT oder OPEN CURSOR ... CLOSE CURSOR auf? Dann sollte aber auch im Hintergrund ein Fehler kommen. Oder läuft irgendeine Art von (BAL)-Logging in eurem System das Benutzeraktivitäten aufzeichnen soll?
Gruss
Coco
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Du musst dann irgendwo in deinem Aufurfer eine Datenbankoperation haben die einen HOLD auf einen Datanbankcursor hat.
Mögliche Situationen die mir einfallen:
Mögliche Situationen die mir einfallen:
- Aufruf zwischen SELECT ... ENDSELECT (auch in anderen Programmteilen wenn es dadurch zur Ausführung des RFC kommt)
- OPEN CURSOR WITH HOLD (Das wird z.B. von BAL verwendet)
- SELECT ... FOR UPDATE
- EXEC SQL ... ENDEXEC (wenn man da drin irgendwas mit Cursor macht)
- CL_SQL_*-Klassen (auch ADBC genannt; wenn man damit irgendwas mit Cursor macht)
- IF_AMDP_*-Interfaces (auch nur AMDP genannt; wenn man damit irgendwas mit Cursor macht)
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Der Fuba DB_COMMIT wird im Rahmenprogramm aufgerufen.
FUNCTION db_commit.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" REFERENCE(IV_DEFAULT) TYPE ABAP_BOOL DEFAULT ABAP_FALSE
*"----------------------------------------------------------------------
IF iv_default = abap_false.
EXEC SQL.
COMMIT WORK
ENDEXEC.
ELSE.
COMMIT CONNECTION default.
ENDIF.
CALL METHOD cl_dbi_transaction_state=>raise_db_transaction_finished
EXPORTING
iv_kind = cl_dbi_transaction_state=>gc_commit.
FUNCTION db_commit.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" REFERENCE(IV_DEFAULT) TYPE ABAP_BOOL DEFAULT ABAP_FALSE
*"----------------------------------------------------------------------
IF iv_default = abap_false.
EXEC SQL.
COMMIT WORK
ENDEXEC.
ELSE.
COMMIT CONNECTION default.
ENDIF.
CALL METHOD cl_dbi_transaction_state=>raise_db_transaction_finished
EXPORTING
iv_kind = cl_dbi_transaction_state=>gc_commit.
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Darf er aber nicht 😉
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
verstehe ich dich richtig, dass das die Ursache ist und an der Stelle nicht sein darf/sollte? Dann heißt es, dass im Standard Rahmenprogramm ein Fehler ist und ich mich an SAP wende... Habe ich das richtig interpretiert?
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Ja, das ist die Ursache für den Kurzdump. Aber das eigentliche Problem liegt an einer anderen Stelle.
Was meinst du mit "Standardrahmenprogramm"?
Ich dachte du verwendest ein Z-Programm für die Abfrage und hast da irgendwo ein SELECT oder ähnliches mit einem offenen bzw. gehaltenen Zeiger drinnen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Ich verwende einen Badi, in dem Badi mache ich einen Select Single (das ist nicht die Ursache) und rufe einen RFC Fuba mit Destination auf (führt zum Dump). Das Standardprogramm (SAP Anwendung) durchläuft den Badi und führt dann im Rahmenprogramm den Fuba DB_COMMIT auf.
Okay, hast du eine Idee, wie ich die andere Stelle für das Problem herausfinde?
Okay, hast du eine Idee, wie ich die andere Stelle für das Problem herausfinde?
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Dann ist das Rahmenprogramm leider NICHT für die Funktion gemacht, die du gerne hättest. Irgendwo im Ablauf wird dort ein Cursor geöffnet, der beim Aufruf des RFC geschlossen wird und das Programm abstürzen lässt. Das Problem wirst du auch kaum per OSS oder sonstwie von der SAP behoben bekommen ("wenn man es so verwendet wie es gedacht ist, gibt es den Fehler nicht").
Du musst dir also was eigenes bauen, was ohne das Rahmenprogramm auskommt.
z.B. legst du die Daten aus dem Standardprogramm, die du für den Aufruf des RFC brauchst in einer eigenen Tabelle ab und lässt die Einträge dann in einem eigenen Hintergrundjob abarbeiten. Wenn du das Ergebnis in der Standardanwendung wieder brauchst, musst du eine Möglichkeit finden die Daten wieder zurück zu laden. z.B. ein eigener Dialog mit "EXPORT" und "IMPORT" den der Benutzer bedienen muss.
Du musst dir also was eigenes bauen, was ohne das Rahmenprogramm auskommt.
z.B. legst du die Daten aus dem Standardprogramm, die du für den Aufruf des RFC brauchst in einer eigenen Tabelle ab und lässt die Einträge dann in einem eigenen Hintergrundjob abarbeiten. Wenn du das Ergebnis in der Standardanwendung wieder brauchst, musst du eine Möglichkeit finden die Daten wieder zurück zu laden. z.B. ein eigener Dialog mit "EXPORT" und "IMPORT" den der Benutzer bedienen muss.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
c oco
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
1752
Views
Views
Ermitteln, ob Buchungsdatum in einer geschlossenen Buchungsperiode liegt
von SweetRuedi » 29.05.2020 12:22 • Verfasst in ABAP® Core
von SweetRuedi » 29.05.2020 12:22 • Verfasst in ABAP® Core
0
Antw.
Antw.
2058
Views
Views
Wann können BANFen in ME57 nicht mehr geöffnet werden?
von Legxis » 09.10.2018 14:11 • Verfasst in ABAP® für Anfänger
von Legxis » 09.10.2018 14:11 • Verfasst in ABAP® für Anfänger
8
Antw.
Antw.
8398
Views
Views
Open Dataset & Transfer ergibt fehler: Datei nicht geöffnet
von Thanatos82 » 24.09.2012 09:59 • Verfasst in ABAP® für Anfänger
von Thanatos82 » 24.09.2012 09:59 • 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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.