Sql remote und local

[Robi]

Hi *all
ich hab folgendes SQL problem
(die sql's sind syntaktisch richtig, das ist sicher)


ich versuche mit SQLRPGLE in pgm 1 (actgrp *caller)
connect reset
connect to :Database
(immer mit exec sql und endexec)

in SQLRPGPGM 2 versuche ich ein (actgrp *caller)
declare...
close ...
prepare ...
open ...
fetch first from c1 into :var

in einem CL (actgrp *new)
rufe ich SQLPGM1 mit database 1, dann
sqlpgm2 dann
sqlpgm1 mit database 2 dann
sqlpgm2

Ergebniss:
nix geht, da ich SQLRPGLE mit rdb(*local) umwandel
und kein sqlpackage erzeugt habe,da ich die rdb's für die das lauft nicht kenne (jedenfalls nicht alle) und bei n kundein ich ja n packages bräuchte (oder wie oder was)
Wie ist soetwas zu lösen ?

Danke
Robi

[Fuerchau]

Schau dir mal den Befehl CRTSQLPKG an.
Mit diesem kannst du das SQLPKG auf dem Zielsystem anlegen. Ohne geht leider nichts ! Die Berechtigung auf dem Zielsystem ist allerdings immer *PUBLIC *EXCLUDE.
Aber Achtung:
Immer wenn du an deinem Programm eine Änderung vornimmst, gibt es ein neues SQLPKG. Es funktioniert ähnlich dem Levelcheck. Wenn das Paket nicht passt, kommt keine Verbindung zustande.

Übrigens:
Die beiden SQLRPGLE-PGM'e sollten jeweils in einer eigenen festen Activationgroup laufen !!!

Mit meinem Tool SQLCPY (auf meiner Homepage) kannst du allerdings auch schon einiges erreichen, teste es doch einfach mal.

Alternative:
SQLCLI ! Dies sind C-Routinen, für die du kein SQLPKG benötigst (analog ODBC-Aufrufen).

Achja:
Mit REXX brauchst du auch keine SQLPKG's.

[Robi]

Hallo Furchau,
Danke für die schnelle Antwort.
Crtsqlpkg hatte ich schon gefunden (Aufgrund der Fehlermeldung). Was mir nicht passt(und ich auch nicht recht Begreife) ist, daß ich bei jedem Kunden nach Lieferung der Programme ein CRTSQLPKG auf jeder Maschine machen soll
(Was für ein Verwaltungsaufwand)

SQLCLI wär ja ein Versuch Wert, hast du eine Adresse mit einer kurzen Einführung / Erklährung o.ä ?

Auch Rexx würd ich gerne mal lernen, (selbstverständlich zusätzlich zu dem 10 Stunden Arbeitstag)
Hast du dazu einen Link ?

Warum sollen die SQL's in eine benannten actgrp laufen ?
(Unser Prinzip : 1. Pgm aus Menü = Weiche = actrgp *new,
alle weitern *caller, Recursion (via pgmstack ermittelt) call via Weiche wieder in *new. + wenige ausnamen)

SQLCPY : ist warscheinlich richtig gut, trifft aber auf wenig (Kauf)Zustimmung bei unseren Kunden. Sorry

in der Hoffnung ein(ige) Link(s) zu bekommen
Vielen Dank
Gruß
Robi

Dan

[Fuerchau]

SQLCLI und REXX findest du unter http://publib.boulder.ibm.com/iserie...2924/index.htm

Benannte ACTGRP's sind deshalb von Vorteil, weil die Verbindung zu jeder DB offen bleiben kann. Ansonsten muss man immer mit "connect" die Verbindung umschalten.

Was hindert dich, den CRTSQLPKG aus dem CLP aufzurufen ?

SQLCPY spart aber jede Menge Programmierzeit. Was sind da schon €500 gegen 10 und mehr Stunden Programmieraufwand ?
Ausserdem kann man dann mal "so eben" Daten zwischen Systemen austauschen.

[Robi]

[QUOTE=Fuerchau]SQLCLI und REXX findest du unter http://publib.boulder.ibm.com/iserie...2924/index.htm

Danke, schau ich mir mal an


Benannte ACTGRP's sind deshalb von Vorteil, weil die Verbindung zu jeder DB offen bleiben kann. Ansonsten muss man immer mit "connect" die Verbindung umschalten.

ist in diesem Fall Sinn der Übung, erst alle Daten der
1. AS400, dann alle der 2.

Was hindert dich, den CRTSQLPKG aus dem CLP aufzurufen ?

huch, äh dummheit + unwissen (hat jede as400 mit sql den CRTSQLPKG ?) das währ ja dann ganz einfach !!



SQLCPY spart aber jede Menge Programmierzeit. Was sind da schon €500 gegen 10 und mehr Stunden Programmieraufwand ?
Ausserdem kann man dann mal "so eben" Daten zwischen Systemen austauschen.

Seh ich auch so, ich kann aber nicht den Nutzen direkt Nachweisen + 'Noch ein Softare Anbieter' + 'was ist mit Rel wechsel + was ist wenn wir eine neue as ...

Danke
Robi

[Fuerchau]

Wenn SQL nicht automatisch auf jeder AS/400 verfügbar wäre, könnte man keine Anwendung ohne das SQL-Paket installieren.
Wenn Programme mit embedded SQL ausgeliefert werden, muss das SQL-Produkt selbst nicht installiert sein. Dieses ist nur erforderlich, wenn man STRSQL oder STRQM verwenden will. SQLCLI ist genauso Bestandteil (wird z.B. von REXX verwendet).

Ausserdem kannst du das SQLPKG als separates Objekt (CRTSQLPKG mit *LOCAL als DB) mit ausliefern und auf jedes Zielsystem kopieren lassen (immer in die QGPL).

[Robi]

Heist das, dass ich ein

CRTSQLPKG *local

mache, das Objekt ganz 'normal' mit meinem Projekt auf die Kundenmaschine(n) bringe und ich hab gar kein Problem ?!?

Ich hab ja dann auf beiden AS400 den gleichen Stand!

Wird *local nicht (wie *Libl bei ADDPFTRG) fest mit der DB im Obj verbunden.

Immer Qgpl ? ist das Pflicht oder eine Empfehlung ?

Nochmal Danke
Robi

[Fuerchau]

Mit CRTSQLPKG werden nur die SQL's aus dem Programm extrahiert, an die DB gesendet und das SQLPKG erstellt.
Der Name und die Lib werden durch den Parameter SQLPKG des CRTSQLRPGI festgelegt. Wenn deine Lib natürlich auf jedem System vorhanden ist, brauchst du die QGPL nicht, ansonsten wird auf dem Zielsystem das SQLPKG immer in der Lib gesucht, die beim CRTSQLRPGI angegeben ist. Daher sollte man hier ggf. auf die QGPL ausweichen.

Der CRTSQLPKG verwendet genauso die DB-Angaben des WRKRDBDIRE wie dein Programm beim Connect.

Um eine Verbindung zu einer RDB aufzunehemn MUSS ich diese mittels WRKRDBDIRE bekannt machen.