SQL - Create Table X/Y Angabe Satzformat

[Fuerchau]

Was mir bei SQL native noch fehlt, ist die gleiche Möglichkeit wie bei SQLCLI, den SQL-Prozess als Hintergrundprogramm (QSQSRVR) zu aktivieren. Damit lege ich dann eine nicht unerhebliche Last in Batch.

Kennt jemand da eine Lösung ?

[BenderD]

@Baldur: Diese Lösung ist elementar: Zwei Maschinen sind billiger als eine!!!
- Alle Zugriffe per SQL, Rekord Löffel Exzess komplett ablösen
- eine kleine 250 oder so, für 5250, eine (5)250 sozusagen.
- jetzt darf man von der (5)250 auf die richtige AS400, den Datenbankserver connecten und ist dort im Batch.

Dieter Bender

Was mir bei SQL native noch fehlt, ist die gleiche Möglichkeit wie bei SQLCLI, den SQL-Prozess als Hintergrundprogramm (QSQSRVR) zu aktivieren. Damit lege ich dann eine nicht unerhebliche Last in Batch.

Kennt jemand da eine Lösung ?

[B.Hauser]

Was mir bei SQL native noch fehlt, ist die gleiche Möglichkeit wie bei SQLCLI, den SQL-Prozess als Hintergrundprogramm (QSQSRVR) zu aktivieren. Damit lege ich dann eine nicht unerhebliche Last in Batch.

Kennt jemand da eine Lösung ?

iSeries Navigator Database?

Birgitta

[holgerscherer]

Was mir bei SQL native noch fehlt, ist die gleiche Möglichkeit wie bei SQLCLI, den SQL-Prozess als Hintergrundprogramm (QSQSRVR) zu aktivieren. Damit lege ich dann eine nicht unerhebliche Last in Batch.

RUNSQLSTM? Oder habe ich das falsch gelesen?

-h

[Fuerchau]

Das ist nicht das, was ich meine.

Bei SQLCLI habe ich die Möglichkeit, beim SQLConnect, bzw. SQLSetConnectAttr den SQL-Server in einen Batchprozess zu verlegen. Dieser wird dann im QSYSWRK gestartet und sämtliche SQL-Befehle laufen dann nicht in meinem Dialog-Job, belasten daher nicht die Dialog-CPW sonder gelten als Batch-CPW.

Wie schaffe ich das aber im native SQL in RPG/LE ?

RUNSQLSTM funktioniert eh nur, wenn SQL installiert ist und läuft auch in dem Job, in dem es ausgeführt wird.

Und Dialogprogramme führe ich nicht über den OpsNav aus !

[BenderD]

Hallo Baldur,

wie gehabt: zwei Maschinen; auf die remote Datenbank darfst du connect machen und hängst an einem Serverjob.

Dieter

Das ist nicht das, was ich meine.

Bei SQLCLI habe ich die Möglichkeit, beim SQLConnect, bzw. SQLSetConnectAttr den SQL-Server in einen Batchprozess zu verlegen. Dieser wird dann im QSYSWRK gestartet und sämtliche SQL-Befehle laufen dann nicht in meinem Dialog-Job, belasten daher nicht die Dialog-CPW sonder gelten als Batch-CPW.

Wie schaffe ich das aber im native SQL in RPG/LE ?

RUNSQLSTM funktioniert eh nur, wenn SQL installiert ist und läuft auch in dem Job, in dem es ausgeführt wird.

Und Dialogprogramme führe ich nicht über den OpsNav aus !

[holgerscherer]

wie gehabt: zwei Maschinen; auf die remote Datenbank darfst du connect machen und hängst an einem Serverjob.

Ist auf jeden Fall eine gute Idee. Das könnte man "iSeries-Lizenzadapter" nennen...

Ich habe da noch einen Stapel 170er, den ich dafür anbieten könnte

-h

[Fuerchau]

@Dieter
Jaja, aber wie wärs mit Connect zu Localhost ?
Allerdings halse ich mir da die interne DFÜ (TCP mit Localhost) als Overhead auf. Eigentlich eher unschön. Gibts da noch nix mit QAQQINI ?

[BenderD]

@Baldur: geht nicht, haben die abgeklemmt und damit ihre eigene Datenbank kastriert, wenn man nämlich automatisch connected wird, darf man nur einen Connect und dafür haben die dann den Work around mit dem Commit Scope ActivationGroup gemacht; den habe ich erst verstanden als ich mit Java Datenbank programmiert habe.

Was natürlich schon gehen müsste, wäre ein eigener Pre Compiler für embedded SQL, der aus den SQL/RPG Quellen schnöderweise CLI generiert. (wie wär's mit einem Joint Venture?)

Dieter

@Dieter
Jaja, aber wie wärs mit Connect zu Localhost ?
Allerdings halse ich mir da die interne DFÜ (TCP mit Localhost) als Overhead auf. Eigentlich eher unschön. Gibts da noch nix mit QAQQINI ?

[B.Hauser]

@Baldur: geht nicht, haben die abgeklemmt und damit ihre eigene Datenbank kastriert, wenn man nämlich automatisch connected wird, darf man nur einen Connect und dafür haben die dann den Work around mit dem Commit Scope ActivationGroup gemacht; den habe ich erst verstanden als ich mit Java Datenbank programmiert habe.

Was natürlich schon gehen müsste, wäre ein eigener Pre Compiler für embedded SQL, der aus den SQL/RPG Quellen schnöderweise CLI generiert. (wie wär's mit einem Joint Venture?)

Dieter

Warum nicht gleich die CLI-APIs in RPG einbinden?

Birgitta

[BenderD]

Hallo,
weil:
- embedded SQL komfortabler ist
- Prüfungen in die Compile Time verlagert werden
- ich vorhandene embedded SQL Quellen nicht per Hand umstellen will
- embedded SQL den höheren Standardisierungsgrad als CLI hat
- da eventuell die Chance besteht SQL Packages mit zu erstellen

mfg

Dieter Bender

Warum nicht gleich die CLI-APIs in RPG einbinden?

Birgitta

[Fuerchau]

- Parameter als Hostvariablen verwendet werden können !!!!!
- der SEU zumindest syntaktische Fehler erkennt
- die Funktionen SQLBindCol, SQLBindParm usw. gespart werden
- bessere Unterstützung von Date/Time/Timestamp (Variablen statt C-Strukturen beim CLI)

Das mit den SQL-Packages ist da eher von Nachteil, da ich diese ja erst extrahieren und ins Zielsystem einbringen muss und bei jeder kleinen Änderungen main Programm auf die Schnautze fällt, da ja das SQLPackage im Zielsystem wieder mal nicht aktuell ist.
SQLCLI kommt da ohne aus, bzw. diese werden dynamisch im Zielsystem erstellt.

Ich vermisse allerdings tatsächlich die Nachimplementation im CLI zur Verwendung neuer SQL-Standard-Typen als auch UDT's (etwas schwierig zu verwenden).