View Full Version : Embedded SQL in VARPG
Hallo,
ich wollte gerade embedded SQL in VARPG ausprobieren und bin auf einige Sachen gestoßen zu denen ich einige Fragen hätte.
1. Ich hab gehört man muss für den Zugriff auf die Datenbank etwas in den Erstellungsoptionen angeben. Was muss man dort genau angeben?
2. Laut: http://www.systeminetwork.com/isnetforums/archive/index.php?t-26497.html
muss auf jedem Client die DB2 UDB & SDK installiert werden. Braucht man diese nur zum Entwickeln oder müssen diese später auch bei jedem User installiert werden?
Bzw was brauche ich zum entwickeln und was braucht der User zum ausführen des Programmes?
3. Soweit ich weiß gibt es eine Trial Version für UDB und SDK aber die richtigen Versionen sind dann kostenpflichtig. Gibt es dort auch unterschiedliche Versionen?
4. Reicht für die Benutzung von Emb. SQL "C+ connect to :Database user :UserId using :Password" oder muss man sich nochmal oder irgendwie anders an der Maschine anmelden?
Vielen Dank schonmal im Vorraus!
Gruß Martin
Hallo Martin,
alle Fragen kann ich leider nicht beantworten, da ich
in VARPG kein SQL benutzte.
Wenn SQL verwendet wird muss auch später bei der
Installation auf den Clients die DB2 installiert sein.
Die Version müsste aber bei dem CD Satz dabei sein.
Wenn in meinen VARPG Programmen SQL benötigt
wird, dann benutzte ich immer ein Serverprogramm.
Damit entfällt die Installation für die Clients.
Gruss
Michael
An das Auslagern des SQLs hatte ich auch schon gedacht aber ich wollte erstmal schaun wie es mit VARPG funktioniert, wie groß der Aufwand ist und wieviel das dann kostet. Weil auf jedem Client die DB2 UDB zu installieren wird bestimmt einiges an Kosten verursachen.
Die UDB selber ist nicht nötig sondern nur DB2/Connect.
Ok danke. Um die Kosten scheints aber keinen Weg herum zu geben. :(
Kann mir evtl. jemand sagen was ich bei den Erstellungsoptionen eintragen muss? Bzw ob die 2 DB2 Reiter genug sind und was man bei "DB2-Datenbankname" eintragen muss?
Sind ja nur 8 Zeichen dh. IP, qualifizierter Name oder irgendein Name einer Lib oder eines Files sind es nicht, da diese bis 10 Zeichen lang sein können. Was muss also dort hinein?
Danke!
Gruß Martin
Edit: Ich glaub ich habs. Bei strsql steht ja "Verbindung zur relationalen Datenbank xyz hergestellt." Beim Kompilieren bekomme ich jetzt allerdings den Fehler: "
RNV8539E Das Produkt DB2 wurde während der SQL-Initialisierung nicht gefunden; die Umwandlung wird beendet." Hat jm eine Idee?
Auf der AS/400 kann man mittels WRKRDBDIRE einen Datenbanknamen festlegen. Dieser ist max. 8-Stellig und entspricht meist dem Systemnamen (DSPNETA), der wiederum nur 8-Stellig sein kann.
Wird ein fixer DB-Name eingetragen, schlägt die Verbindung fehl, wenn der angegebene Name nicht identische mit dem RDB-Namen der AS/400 ist.
Das Feld kann freibleiben, da der Systemname zum Verbindungsaufbau vollkommen ausreicht.
Mittels WRKRDBDIRE können andere DB's, die das DRDA-Protokoll unterstützen angebunden werden (meist andere AS/400er).
Beim Connect kann ich also mittels Systemnamen und RDB-Namen dann durchrouten zu einer anderen DB (was nur sinn macht, wenn die anderen DB's nicht direkt erreichbar sind).
Auf der AS/400 kann man mittels WRKRDBDIRE einen Datenbanknamen festlegen. Dieser ist max. 8-Stellig und entspricht meist dem Systemnamen (DSPNETA), der wiederum nur 8-Stellig sein kann.
Wird ein fixer DB-Name eingetragen, schlägt die Verbindung fehl, wenn der angegebene Name nicht identische mit dem RDB-Namen der AS/400 ist.
Das Feld kann freibleiben, da der Systemname zum Verbindungsaufbau vollkommen ausreicht.
Mittels WRKRDBDIRE können andere DB's, die das DRDA-Protokoll unterstützen angebunden werden (meist andere AS/400er).
Beim Connect kann ich also mittels Systemnamen und RDB-Namen dann durchrouten zu einer anderen DB (was nur sinn macht, wenn die anderen DB's nicht direkt erreichbar sind).
Ich habe gerade nachgeschaut, der RDB Name auf der As400 ist derselbe den ich angegeben habe. Damit sollte der Fehler nichts zu tun haben. Kann es sein das der Fehler zustande kommt weil ich zz nur eine Trialversion der DB2 UDB habe? Da der Fehler mit nicht zu findenden DLLs zusammenhängt, fehlen in der Trialversion vtl DLLs?
EDIT: Mittlerweile scheint er die DLLs zu finden. jetzt mag er jedoch meinen DB2-Datenbanknamen nicht mehr.
RNV8533E Nicht behebbarer Fehler während SQL-Initialisierung aufgetreten: SQL1013N Der Aliasname der Datenbank oder der Datenbankname "ABCDEFGH" wurde nicht gefunden. SQLSTATE=42705
Das ist aber genau der der bei "WRKRDBDIRE" auch steht.
Und anscheinend muss ich das bei den Erstellungsoptionen angeben da er sonst meckert das ich dort etwas einstellen soll.
EDIT2: MUss man evtl bei der Db2 Udb noch etwas einstellen?
Habe die Fehler oben mittlerweile alle behoben. Bin wieder bei programmiertechnischen, diesmal syntactischen Fehlern angelangt.
C/EXEC SQL
C+ whenever SQLERROR goto SQLABEND
C/END-EXEC
*
C/EXEC SQL
C+ connect to :Database user :UserId using :Password
C/END-EXEC
C/EXEC SQL
C+ Declare MyCsr Cursor for
C+ Select * From TABLE where NAME = :NAME
C/End-Exec
C/EXEC SQL
C+ Open MyCsr
C/END-EXEC
C
C do *HIVAL
C/EXEC SQL
C+ Fetch Next from MyCsr
C+ into :NAME,
C+ :RECORD,
C+ :DESC
C/END-EXEC
C/EXEC SQL
C+ Close MyCsr
C/END-EXEC
C/EXEC SQL
C+ connect reset
C/END-EXEC
Ich bekomme jedoch beim Fetch einen Fehler:
C+ Fetch Next from MyCsr
RNV8526E Anweisung /EXEC SQL enthält Fehler: SQL0104N Auf "<Kennung>" folgte das unerwartete Token "FROM". Zu den m”glichen Token geh”ren: "INTO".
Ich habe das so aber schon öfter gesehen. Also Fetch Next from CURSOR into :VAR1, :VAR2
Wo liegt mein Fehler?
Vielen Dank.
Gruß Martin
EDIT: Ich kann auch keinen Qualifizierten Namen angeben im Format LIB/FILE. Da bekomme ich die Fehlermeldung das:
Ursache . . . . : Einer der folgenden Fehler trat auf:
-- Die für den qualifizierten Objektnamen verwendete Syntax ist für die
angegebene Benennungsauswahl nicht gültig. Bei der Systembenennung ist die
qualifizierte Form eines Objektnamens Schemaname/Objektname. Bei der
SQL-Benennung ist die qualifizierte Form eines Objektnamens
Berechtigungsname.Objektname.
-- Die für den qualifizierten Objektnamen verwendete Syntax ist nicht
zulässig. Benutzerdefinierte Datenarten können in der Systemnamenskonvention
in Parametern und SQL-Variablen einer SQL-Prozedur oder -Funktion nicht mit
dem Schema qualifiziert werden.
Wenn ich mir nur ein SQLRPGLE Programm schreibe funktioniert beides wunderbar.
Nochmal wegen dem oben. Habe versucht eine Verbindung via ODBC aufzubauen, was auch funktionierte aber ich sah nur die Systemtabellen nicht die normalen Libraries. Könnte das jetzt nicht auch der Fall sein? Das würde erklären warum es nicht funktioniert.
Ich habe die Verbindung zum Server über DB2 UDB-Steuerzentrale getestet. Das funktioniert aber nur über den "Standart". als ich dann in der normalen Steuerzentralensicht auf die tabellen zugreifen wollte, will er sich mit CLI verbinden was aber nicht funktioniert. Wie kann ich die Verbindung auf "Standart" umstellen bzw was muss ich tun damit es mit CLI funktioniert?
EDIT: CLI-Verbindung ist fehlgeschlagen.
SQL30082N Die Verbindung konnte auf Grund der Sicherheitsbedingung "24" ("USERNAME AND/OR PASSWORD INVALID") nicht hergestellt werden. SQLSTATE=08001.
- Aber Pwd und Userid müssen stimmen weil die normale "Standartverbindung" funktioniert.
Bei der Steuerzentrale bekomme ich die Fehlermeldung wenn ich die Tabellen abrufen will:
[IBM][CLI Driver][AS] SQL0805N Paket "NULLID .SYSSH200" nicht
gefunden. SQLSTATE=51002
Erklärung:
Die Anweisung kann nicht beendet werden, da das erforderliche
Paket im Katalog nicht gefunden wurde.
Das Paket "<name-des-pakets>" weist eines der folgenden Formate
auf:
o 'paketschema.paketname 0Xkontoken', wobei das Konsistenztoken
in hexadezimaler Form angegeben wird.
o 'paketschema.paketname.paketversion'. Wenn die Paketversion
eine leere Zeichenfolge ist, fällt der Teil '.paketversion'
weg.
o '%.paketname'. Wenn für den Parameter CURRENT PACKAGE PATH
ein Wert festgelegt wird. Die Gruppe mit Schemanamen im
Parameter CURRENT PACKAGE PATH wird durch das Prozentzeichen
('%') festgelegt.
Mögliche Ursachen für den (SQLCODE) dieser Nachricht:
o Das Paket wurde nicht gebunden oder es wurde gelöscht.
o Für die Ausführung eines DB2-Dienstprogramms oder einer
CLI-Anwendung kann es erforderlich sein, die
DB2-Dienstprogramme erneut an die Datenbank zu binden.
o '%.paketname'. Wenn für den Parameter CURRENT PACKAGE PATH
ein Wert festgelegt wird, jedoch in keinem Schema im
Parameter CURRENT PACKAGE PATH ein Paket mit dem Namen
'paketname' gefunden wurde.
Wenn die Versions-IDs für paketschema.paketname bereits
verwendet werden, können Pakete vorhanden sein, deren Schema und
Name übereinstimmen. Das korrekte Paket wird jedoch nicht
gefunden, da die vorhandenen Pakete nicht mit der erforderlichen
Version bzw. dem erforderlichen Konsistenztoken übereinstimmen.
Für ein Paket müssen alle drei Bestandteile des Paketnamens
übereinstimmen. Bei Verwendung mehrerer Versionen kann diese
Nachricht auch aus den folgenden Gründen ausgegeben werden:
o Die Version der ausgeführten Anwendung wurde vorkompiliert,
kompiliert, und es wurde eine Verbindung hergestellt. Die
Anwendung wurde jedoch nicht gebunden, oder sie wurde
gebunden, aber diese Version des Pakets wurde gelöscht.
o Die Anwendung wurde zwar vorkompiliert und gebunden, aber sie
wurde nicht kompiliert, und/oder es wurde keine Verbindung
hergestellt. Deshalb ist die ausgeführte Anwendung nicht
aktuell.
o Das Paket wurde anhand einer Bindedatei gebunden, die durch
eine andere Vorkompilierung der Quellendatei generiert wurde
als die Vorkompilierung, aus der die geänderte Quellendatei
hervorging, die kompiliert und mit der ausführbaren Datei der
Anwendung verbunden wurde.
o Eine neue Anwendung wurde mit dem Namen (und der Version)
eines bereits vorhandenen Pakets gebunden, so dass das
vorhandene Paket ersetzt wurde. Wenn die dem ersetzten Paket
zugeordnete Anwendung ausgeführt wird, kommt es zu diesem
Fehler.
In allen genannten Fällen entspricht das Konsistenztoken der
Anforderung nicht dem Konsistenztoken der vorhandenen Version.
Deshalb wird das Paket nicht gefunden.
Die Anweisung kann nicht verarbeitet werden.
Benutzeraktion:
Korrigieren Sie den Namen des Pakets, oder binden Sie das
Programm. Wenn die ausgeführte Anweisung nicht an die Datenbank
gebunden ist, bitten Sie den Datenbankadministrator, die
erforderlichen Bindeoperationen durchzuführen. Stellen Sie sicher,
dass es sich bei der ausgeführten Anwendung bzw. dem ausgeführten
Objektmodul um den kompilierten und verbundenen geänderten
Quellcode handelt, der dem Befehl PRECOMPILE und BIND zugeordnet
wurde, der das Paket generiert hat.
Wenn für den Parameter CURRENT PACKAGE PATH ein Wert festgelegt
wird, stellen Sie sicher, dass das Schema, in dem das Paket
enthalten ist, im Parameter CURRENT PACKAGE PATH angegeben
wird.
Die folgenden SQL-Anweisungen können zur Abfrage des Katalogs
verwendet werden, um festzustellen, ob unterschiedliche
Paketversionen vorhanden sind.
SELECT PKGSCHEMA, PKGNAME, PKGVERSION, UNIQUE_ID
FROM SYSCAT.PACKAGES
WHERE PKGSCHEMA='paketschema' und PKGNAME='paketname'.
Beachten Sie, dass die Spalte UNIQUE_ID dem Konsistenztoken
entspricht.
Falls die DB2-Dienstprogramme erneut an die Datenbank gebunden
werden müssen, kann der Datenbankadministrator dies mit einem der
folgenden CLP-Befehle vom Unterverzeichnis bnd des Exemplars aus
vornehmen, während er mit der Datenbank verbunden ist:
o "DB2 bind @db2ubind.lst blocking all grant public" für die
DB2-Dienstprogramme
o "DB2 bind @db2cli.lst blocking all grant public" für CLI.
Benutzer eines Systems zusammengeschlossener Datenbanken:
Stellen Sie sicher, dass die für den Server mit
zusammengeschlossenen Datenbanken erforderlichen Pakete in den
entsprechenden Datenquellen gebunden werden. Weitere
Informationen zum Binden von Paketen enthält das Handbuch Systeme
zusammengeschlossener Datenbanken .
sqlcode : -805
sqlstate : 51002
EDIT2: Teilweise scheint CLI zu funktonieren. Beim Test des Assistenten sagt er "CLI-Verbindung erfolgreich getestet" aber auf Tabellen kann ich trotzdem nicht zugreifen.