[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Jan 2003
    Beiträge
    231

    JVAGATE und SQLRPG auf lokale DB2 for i

    Hallo zusammen,
    ich verwende JVAGATE für den Zugriff auf verschiedene ext. Datenbanken, funktioniert alles super. (Thx DB).
    Jetzt ist eine Oracle-DB (FIBU) dazugekommen, funktioniert auch generell.
    Die Verarbeitung habe ich in SQLRPG-Pgm's, dort connecte ich zu den DB's, Öffne Cursor, leses Sätze, schließe Cursor und schliesse die Verbindung wieder !
    Die Oracle-DB arbeitet mit Commit, wir auf unseren lokalen DB2 for i ohne Commit !

    Nur in Verbindung (kein direkter CALL) mit einem anderen SQLRPG-Pgm, das auf die lokale DB2 zugreift, bekomme ich immer den Fehler SQL0900..."Anwendungsprozess befindet sich nicht in einem Status, der eine Verbindung zulässt."

    Der Ablauf ist wie folgt:
    Der Anwender ruft über das Menü das SQLRPG-Pgm1 auf, mit dem ich ausschließlich (SQL-mäßig) auf die Oracle-DB zugreife (Anzeige OP-Salden von Kunden aus FIBU Oracle).
    Alles wunderbar, wenn der Anwender fertig ist drückt er F3, ich mache im SQLRPG-Pgm1 dann ...

    exec sql commit;
    exec sql release PROD10PDB;
    exec sql disconnect PROD10PDB;


    Dann geht der Anwender in einen anderen Menüpunkt und ändert Stammdaten.
    Dabei läuft dann über einen Trigger das SQRPG-Pgm2 mit Zugriff auf die lokale DB2, und dort bekomme ich dann den o.g. Fehler.
    Habe auch schon versucht, in diesem SQLRPG-Pgm2 einen "connect" auf die lokale DB2 auszuführen, der Fehler ist immer der gleiche !

    Ich vermute den Fehler aber im SQLRPG-Pgm1 beim "Schliessen" der Verbindung zur Oracle-DB, denn wenn ich nach Aufruf des 1. SQLRPG-Pgm z.B. interaktiv STRSQL aufrufe, bekomme ich in der Sitzung den gleichen Fehler angezeigt.
    Dort reicht dann aber ein Connect to zur lokalen DB2 !

    So öffne ich die Verbindung zur Oracle-DB im SQLRPG-Pgm1...:
    exec sql connect to PROD10PDB;

    Und so schliesse ich diese wieder im SQLRPG-Pgm1...:
    exec sql commit;
    exec sql release PROD10PDB;
    exec sql disconnect PROD10PDB;


    Hier habe ich auch schon einmal ein Connect reset versucht, aber ohne Erfolg.

    Wenn man sich dann an der 5250-Sitzung abmeldet, dauert das eine gewisse Zeit, das Jobstatus wird "Rollback" angezeigt !

    Kann mir jemand sagen, wie man in einem SQLRPG-Pgm unter Verwendung von JVAGATE eine Verbindung zu der "fremden DB" aufbaut und wieder korrekt schließt inklusive "Re/Weider" Verbindung zur lokalen DB2 ?

    Danke vorab + Vg.

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    18.073
    Das Öffnen und Schließen ist gar nicht das Problem sondern die Sonderbehandlung der Commit-Steuerung (wusste ich bis Dieter mir das erklärte auch nicht):
    Der Commit/Rollback wird nicht über SQL direkt verarbeitet und wird auch nicht in den Versionen CMD-Commit, native RPG Commit oder exec sql commit; unterschieden und geht an alle geöffneten Verbindungen gleichzeitig.
    Nur wenn der Commit von allen DB's bestätigt ist, akzeptiert ihn das System.
    Wenn eine RDB-Sitzung geschlossen werden soll (Disconnect) wird dies also bei fehlendem Commit ebenso abgelehnt.
    Dies löst letztendlich auch dein Problem aus.

    Die einzige Lösung in diesem Fall ist, deinem Triggerprogramm eine eigene benannte ACTGRP zu geben, da diese dann auch eine eigene Commit-Definition erhält.
    Zusätzlich ist "exec sql set option commit= *chg;" erforderlich. Daran kann man auch sehen, dass dies nicht verbindungsspezifisch ist also auch für deine aktuelle Verbindung gilt.
    Ein korrektes Schließen ist wirklich nur mit erfolgreichem Commit möglich.

    Solltest du während der Bearbeitung durch den Trigger noch auf eigene nicht journalisierte Dateien zu greifen, so ergänze die SQL-Befehle alle mit " ... with NC" (mit ohne commit). Dann bekommst du keinen Fehler bei fehlendem Journal und ein Commit funktioniert dann.

    Langfristiger würde ich das Triggerverfahren aber asynchronisieren, da der Connect/Update/Close durchaus mal länger dauern kann und auch bei Nichterreichbarkeit deine Dialogsitzung vollkommen ausbremst.
    Dazu kann man ganz gut mit DTAQ's arbeiten, auf denen ein Batchprogramm horcht und die Aktionen ausführt. Dein Trigger schickt dann einfach nur eine Nachricht an die DTAQ (Datei + Key) und und protokolliert die Daten ggf. noch in einer weiteren kleinen Tabelle.
    Der DTAQ-Watcher bekommt die Nachricht sofort aus allen Jobs, erledigt sein Werk und löscht den Satz aus der Protokolldatei.
    Die Protokolldatei ist erforderlich, da DTAQ's auch schon mal kaputt gehen.
    Dann kann man diese wiederherstellen und aus den nicht gelöschten Protokollsätzen die Aufträge wieder in die DTAQ schieben.

    Per Prestart-Job kann man dann sogar mehrere Jobs parallel dranhängen, falls mal 1 nicht ausreichen sollte.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Mar 2002
    Beiträge
    4.815
    ... entscheidend ist hierbei zuerst die ACTGRP, die folgende Eigenschaften hat:
    - eine ACTGRP kann mehrere Connections haben
    - davon kann nur eine aktiv sein
    - wird diese geschlossen, hat sie keine aktive connection (was zum SQL0900 führen kann)
    - mit set connection wechselt man die aktive connection
    - connect reset wechselt zur lokalen Connection
    - Commit scope ist im default die ACTGRP (das sollte man auch so lassen)
    - connect und disconnect gehen nicht innerhalb einer Transaktion

    Die korrekte Vorgehensweise muss immer sicherstellen, dass ein Programm, das remote connections aufmacht, immer so verlassen wird, dass die lokale Connection die aktive ist - also immer connect reset vor dem verlassen (sonst müsste man ja alles anpacken, was danach im Job in der ACTGRP noch passiert).
    Am Ende macht man am einfachsten:
    exec sql release myremote;
    exec sql commit;
    exec sql connect reset;

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  4. #4
    Registriert seit
    Jan 2003
    Beiträge
    231
    Hallo Fuerchau,
    danke für die ausführliche Beschreibung.
    Ich werde zeitnah mal ein Test machen.
    Grundsätzlich ist das Arbeiten mit DTAQ auch nicht schlecht, bei den Triggern habe ich mich seinerzeit für eine "direkte" Verarbeitung entschieden, weil die Anwender die meisten Daten vollkommen ungeprüft "reinkloppen" können, Änderungen daran will die Firma auch nicht mehr investieren !
    Danke + Vg.

  5. #5
    Registriert seit
    Jan 2003
    Beiträge
    231
    Hallo D*B,
    danke für die Infos.
    Ich werde das Programm entsprechend ändern und testen.
    Ich schreib dann wenn ich weiß ob und wie es funktionert !
    Danke + Vg.

  6. #6
    Registriert seit
    Jan 2003
    Beiträge
    231
    Hallo Fuerchau und D*B,
    ich habe nun beides gemacht, das SQLRPG-PGM2 (Zugriff auf lokale DB) habe ich in einer eigenen ACTGRP, und die Programme mit Zugriff auf die externe DB habe ich mit den 3 von D*B angegebenen Befehlen beendet.
    Läuft super, keine Fehler mehr !
    Danke nochmals !
    Vg.

Ähnliche Themen

  1. jvagate Bander tool Verbindung -> Oracle Hilfee
    Von labm im Forum NEWSboard Programmierung
    Antworten: 20
    Letzter Beitrag: 05-06-18, 08:09
  2. Eine lokale Datei lesen/schreiben*** C:\test.txt
    Von svit im Forum NEWSboard Programmierung
    Antworten: 21
    Letzter Beitrag: 30-01-17, 09:45
  3. Problem mit JVAGATE von D.Bender
    Von svit im Forum NEWSboard Programmierung
    Antworten: 14
    Letzter Beitrag: 18-09-14, 11:14
  4. SQLRPG
    Von malzusrex im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 27-02-03, 11:59
  5. SQLRPG
    Von Ursus im Forum IBM i Hauptforum
    Antworten: 10
    Letzter Beitrag: 13-08-01, 07:05

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •