embbed Sql - connect

[LSMD]

Guten Tag,
(ja ich weiß das es embedded heißt ... sorry)

ich versuche ein Programm zu schreiben was auf verschiedenen Maschinen ausgeführt wird und auf eine Maschine zugreift.

ein bisschen Sourcecode:

DEBUG OPTION(*SRCSTMT:*NODEBUGIO)
C/exec sql
C+ connect reset
C/end-exec
C/exec sql
C+ CONNECT TO SYSTEM_A user :a_usr using :a_pw
C/end-exec


Compiler Optionen:

RDBCNNMTH *DUW(*SUW hab ich auch ausprobiert)
COMMIT *CHG
RDB > SYSTEM_A
USER a_user
PASSWORD a_pw
DBGVIEW *Source




Nun das Funktioniert, wenn ich von Maschine_B auf Maschine_A connecte. Nun starte ich die Wandlung auf Maschine_C. Dort sagt er mir erstmal das die Bibliothek geblockt wird. Ich beende meine Sitzung auf Maschine_B und schon klappt es. Das Programm klappt auch auf Maschiene_C. Nur dann auf Maschine_B nicht mehr. Dort bekomm ich als SQLSTATE: 42977
The authorization ID cannot be changed when connecting to the local server.
ODER bei *RUW
0A001 The CONNECT statement is invalid, because the process is not in the connectable state.

Es funktioniert als bei mir nur EINE verbindung.
Wenn ich aber mit STRSQL die Verbindungen aufbaue funktioniert es.

Leider war google diesmal nichtmein Freund :( und die boardsuche konnte mich auch nicht leiden. Insofern dies nur eine persönliche Abneigung war entschuldige ich mich und bitte verlinkt den entsprechenden Thread hier hin.


also kurze zusammen Fassung:

System_C und System_B sollen per embedd SQL auf System_A zugreifen. Leider klappt es nur von System_C ODER System_B.

pls Help

mfg LSMD

[Robi]

Hi,
ich bin zwar nicht DER Commitment Experte, vermute aber, das du im Pgm "insert" oder "update" machst ohne commit.

Dann könnte es sein das du nicht an die Tabelle kommst, solange der andere Job diese sperrt.

Robi

[Fuerchau]

Erst mal noch folgendes zur Vorbereitung:

Embedded SQL erstellt ein programminternes SQLPKG, dass du per

CRTSQLPKG PGM(MYPGM)
RDB(SYSTEM_X)
USER(MYUSER)
PASSWORD(mypassw)

auf dem Zielsystem erstellen musst.
Ggf. macht das die SQL-Runtime inzwischen automatisch.

Dieses SQLPKG wird mit *Public *EXLUDE erstellt, die Lib ist per Default QGPL (kann per "set option" geändert werden).

Nach jeder Umwandlung des Programmes ist leider die Signatur des SQLPKG's immer eine andere, so dass das Paket neu erstellt werden muss.

Deshalb macht es auch keinen Sinn, das Programm jeweils auf SystemA und SystemB neu zu wandeln, da der eine dem anderen das SQLPKG durch Neuerstellung auf SystemC wieder wegnimmt.
Durch *PUBLIC *EXCLUDE fehlt aber ggf. die Berechtigung zum Ersetzen des SQLPKG's.

Die Compileroption RDBCNNMTH dient wirklich nur dem Compiler um die SQL's zu analysieren, Beschreibungen zu laden usw., deshalb ist diese zur Laufzeit nicht mehr relevant.

CONNECT RESET geht natürlich erst, wenn du vorher bereits einen CONNECT TO erfolgreich durchgeführt hast.

Zur Performance ist da leider noch was zu sagen:

Wenn du in einem Programm mit 2 RDB's (fern und lokal) gelichzeitig arbeiten willst, wirst du dich ganz schön wundern.
Jeder CONNECT TO prüft natürlich erneut die Berechtigung und das SQLPKG auf dem Zielrechner und ist deshalb arg langsam.
Solltest du also häufig zwischen CONNECT TO und CONNECT RESET wechseln bricht die Performance drastisch ein.

Ich habe deshalb für solche Aufgaben immer 2 Programme mit jeweils getrennten benannten ACTGRP's erstellt.
Programm A arbeitet mit der fernen DB und ruft Programm B mit der lokalen DB auf. Dies ist um Faktoren schneller.
Ausserdem enthebt mich dieses der Umschaltproblematik und der ggf. unterschiedlichen Journale, da jede ACTGRP in einem anderen Journal aufgezeichnet werden darf (A remote, B lokal).

[BenderD]

... da gehts ja wieder bunt durcheinander (in Fragen und Antworten)

- das benötigte Package wird bei deinem CRTSQLRPGI auf der Maschine SYSTEM_X mit erstellt (Parameter RDB) und zur Compiletime werden statische SQL Statements dort geprüft.

- *DUW sorgt dafür, dass man die Connections hin und her switchen kann

Connection wechseln erfolgt mit set connection <Name in RDBDIR> - das koste auch keinen Strom und es ist unnötig da irgendwelche Klimmzüge zu machen!!!

AM Ende des Programmes muss dann entweder erst ein COMMIT und dann ein DISCONNECT kommen, oder ein RELEASE und dann ein COMMIT ansonsten ist das Package in Benutzung.

Beendet man mit RELEASE ALL oder DISCONNECT ALL, kann man mit CONNECT RESET erneut lokal verbinden.

Wenn man von mehreren Maschine A und B auf C zugreifen will, kann man auch beim CRTSQLRPGI als RDB *LOCAL angeben und dann einmal ein CRTSQLPKG.

D*B

[LSMD]

schließ ich daraus richtig das die Programme auf system b und system C anders heißen müssten damit sie "gleichzeitig" auf System A zugreifen können? Oder kann ich durch eine Option die Programme auf andere SQLpkg's zeigen lassen?

Ich bin ja von der iseries gewohnt workarounds bauen zu müssen.
:confused::confused::confused:
Wie sieht das ganze denn dann bei dynamic SQL aus? ich mein wenn ich auf System_B strsql connect System_A mache und auf System_C das gleiche klappt das ja auch ...

[BenderD]

... aus was schließt du das???
Du kannst nur kein Package neu erstellen, wenn es in Benutzung ist, ansonsten kann das allenfalls dazu führen, dass ein Zugriffspfad nicht aktualisiert wird.
Was natürlich nicht geht, dass du auf Sytem A und Sytem B zwei verschiedene Programme QUATSCH hast, die auf C mit einem einzigen SQL Package Quatsch unterschiedlichen Quatsch machen sollen.

D*B

[LSMD]

Vielen dank =)

Mein Fehler war der Versuch das Programm auf den einzelnen Maschinen neu zu wandeln. Jetzt habe das Programm einmal gewandelt und das Objekt verteilt und siehe da... es läuft.


mfg LSMD