View Full Version : JVAGATE offene Commits im Joblog
Guten Morgen,
wie geht man dann vor, damit die Tabelle gefunden wird, ohne die Bibliothek beim SQL Befehl angeben zu müssen? Wie gesagt im CL davor, wird die Libl festgelegt.
Danke.
Klaus
Guten Morgen Klaus,
ich bin zwar kein Freund von Datenbank und LIBL und halte das für Altlasten oder einen Designfehler, aber zuweilen muss man mit dem leben, was man vorfindet. SET SCHEMA ist nicht dasselbe, wie der Zugriff per LIBL (zuweilen sind Testumgebungen Vorschaltlibs, die nur einen Teil der Objekte enthalten, oder es gibt Mandanten spezifische Vorschaltlibs...) und das Handling ist auch ein wenig tricky (es wird unterschieden nach naming und static/dynamic SQL). Genauer und einfacher ist es, im Programm selber (beim init) die Bibliothek des Objektes per RTVOBJD oder API zu ermitteln und dann beim SQL mit einer Variablen zu qualifizieren.
D*B
Danke Euch. Ich hatte die Hoffnung, dass man mit set path = lib1, lib2 sich quasi eine Liste setzen kann, aber das funktioniert irgendwie nicht. Im RPG kann man mit sqlpath sich eine liste setzen, aber das ist halt nur zum Zeitpunkt der Umwandlung. Dann halt doch im SQLRPG entsprechend das SQL mit einer Variablen zu qualifizieren.
Set Path in SQL entspricht lediglich dem CHGLIBL und kann nur bei *SYS sinnvoll verwendet werden.
Ich stimme Dieter da zu. Allerdings gibt es u.a. auch Sachzwänge bei Standardprodukten, um die man herumstricken muss.
Manche ERP-Anbieter erlauben noch nicht mal, einen Index an ihren Tabellen anzuhängen. Damit würde das ERP-Schema nicht mehr passen, Releaseupdates nicht mehr möglich oder was einem sonst noch so einfällt.
Was ILE angeht so ist es tatsächlich mit ACTGRP's releativ einfach per set Schema den Default zu individualisieren. Man bekommt nur Probleme, wenn man Daten des ERP mit den eigenen Daten in einer Transaktion verarbeiten möchte.
Dies scheitert dann auch bereits, wenn die Schemas in unterschiedlichen Journalen aufgezeichnet werden.
Schemas mit Variablen zu qualifizieren klappt allerdings nur bei dynamischen SQL's.
Alles was Objekte im SQL-Statement angeht, Schema, Table, Column, ist im statischen SQL nicht dynamisierbar. Vielleicht wird das ja doch mal irgendwann erweitert.
Ein Set Schema vor dem Open reicht i.d.R. Allerdings beim Join auf eigene und ERP-Tabellen scheitert man dann schon wieder.
ArdGate klappt ja nun nicht mit statischem SQL, was manchmal halt mühsam ist.
Aber die SQL's kann man sich auch häufig ert mal per ODBC-Zugriffen via z.B. Squirrel zusammenstricken.
Bei entsprechender Überlegung und dem von Dieter angesprochenen Design lässt sich jedoch alles lösen.
ArdGate klappt ja nun nicht mit statischem SQL, was manchmal halt mühsam ist.
Wie meinst Du das? Das machen wir doch so aktuell!
Excec DROP TABLE xx und nicht drop table &lib.xx
Man bekommt nur Probleme, wenn man Daten des ERP mit den eigenen Daten in einer Transaktion verarbeiten möchte.
Dies scheitert dann auch bereits, wenn die Schemas in unterschiedlichen Journalen aufgezeichnet werden.
ArdGate klappt ja nun nicht mit statischem SQL, was manchmal halt mühsam ist.
... das mit den Journalen war einmal und ist nicht mehr.
Delete, insert, update, create, drop etc. geht auch static, call geht nur dynamic, lesen nur dynamic mit cursor.
D*B
Nun ja, das mit dem dynamischen SQL hat sich z.ZT. ggf. ja erledigt, da der SQL-Precompiler ja alles akzeptiert, egal ob es vorhanden ist oder nicht, hauptsache die Syntax stimmt.
Früher gabs was auf die Finger wenn ein Feld nicht da ist. Jetzt könnte ja alles eine Variable sein.
Allerdings ist man bei manchen DB's auf dynamisches SQL angewiesen, da es bei Casts da durchaus spezifische Varianten gibt.
Und so, wie der SQL-Server keine Anführungszeichen für Namen mag, mag die IBM i keine eckigen Klammern.
Guten Morgen,
noch eine Frage:
Wegen der dynamischen LIB habe ich eine Variable tablename definiert und wollte diese in exec sql einbinde, leider motzt der Precompiler.
c/exec sql
c+ update :tablename set changerid = :W_userid
c+ where id = :W_Id
c/end-exec
:tablename wird durch den precompiler angemotzt.
SQL0104 30 171 Position 16 Token : was not valid. Valid tokens:
<identifier>
Eventuell muss ich den kompletten SQl String in eine Variable packen?
c/exec sql
c+ execute immediate :W_Sql
c/end-exec
Danke.</identifier>
... das ist eigentlich SQL Basiswissen, Dateinamen, Feldnamen, etc müssen bei static SQL zur Umwandlungszeit feststehen. Ansonsten dynymic mit prepare und execute using.
prepString = 'update ' + tablename + ' set afield = ? where somefield = ?';
exec sql prepare myStatement from :prepString;
exec sql execute myStatement using :afield, :somefield;
D*B
PS: Margery (AKA die allwissende Müllhalde, alias google) hat zahlreiche Beispiele für prepare execute und warum man Parameter Markers verwenden soll.
@Dieter, vielen Dank.
Eine Frage noch zu JVAGATE.
Wenn wir bei der fernen DB Sätze sperren und der User zum Beispiel blöderweise das X drückt, dann kommt das Programm nicht in die PSSR und die Sätze bleiben gesperrt und zwar solange bis JVAGATE beendet ist (läuft bei uns als ASYNC JOB).
Gibt es hier eine bessere Lösung, sprich eventuell über einen Timeout konfigurierbar in der JVAGATE Config Datei?
Danke.
Klaus
Dann ist das Design fehlerhaft.
Innerhalb einer Transaktion darf es nicht zu einer Userinteraktion kommen.
Also alles mit Monitor umschließen und mit Commit bei OK sowie Rollback bei Fehler beenden.
Damit kann keine Sperre offenbleiben, denn beim Lesen wird nichts gesperrt.