RPG-CALL mit Parameter aus VB...

[Fuerchau]

Jedes "?" bedeutet einen Parameter!

Bei IN-Parametern kann der SQL-Treiber die korrekte Umsetzung selber durchführen.
Bei OUT/INOUT-Parametern ist eine Beschreibung der Parameter erforderlich, da keine automatische Anpssung möglich ist.

Daher die Beschreibung der Parameter:
as400cmd.Parameters.Append as400cmd.CreateParameter("PARM1", adChar, adParamOutput, 1)

Beim Zugriff auf die Parameter mit Index wird der CommandText an den Treiber (und damit an die AS/400) zur Ermittlung der Anzahl Parameter gesendet.
Wenn dann die Syntax e.g. nicht stimmt, kommt es zu einer Ausnahme.

"?" gelten als sog. Parametermarker und sind bei der wiederholten Ausführung erheblich schneller. Viele Programme arbeiten immer noch mit voll dynamischem SQL (geht ja so schön einfach mit VB), was die AS/400 aber zwingt den SQL immer neu zu analysieren, Zugriffswege zu ermitteln usw.
Definiere ich einen SQL aber mit "?", erfolgt die Analyse nur 1 Mal und die Ausführung (Execute) erfolgt sofort.
Ausserdem ist die Programmierung damit erheblich einfacher, als jedesmal die SQL zusammenzusetzen.
Problematisch ist das nähmlich bei Zeichenketten, die selber ein Hochkomma enthalten. Bei Parametermarkern braucht man sich nicht zu kümmern, beim zusammengsetzten SQL müssen diese aber verdoppelt werden.
Beim internationalen Einsatz ist auch noch Decimalpoint/Decimalcomma entscheidend, was bei "?" keine Rolle spielt.

Wie übergebe ich nun Parameter ?
IN/INOUT-Parameter können entweder vor dem Execute mittels Zugriff erfolgen:
as400cmd!Parm1 = Wert ' wenn der Parameter einen Namen hat
as400cmd(0) = Wert ' über Index
oder im Execute selber als Array im 2.Parameter (daher mein Beispiel).

OUT-Parameter können halt nicht übergeben werden, aber trotzdem kann dies über Execute erfolgen, wenn man eine Mischung mit IN/OUT hat:
as400cmd.Execute(, Array(Inparm1, Inparm2, ,InoutParm4),)

Anmerkung:
Für einen korrekten Namen der Prozedur solltest du nicht QTEMP wählen, da Prozeduren (im Gegensatz zu anderen QTEMP-Objekten) NICHT wieder entfernt werden. Ich habe nur QTEMP gewählt, weil ich ja QCMDEXC aufrufen wollte.

Wenn die Prozedur vorhanden ist, aber geändert werden muss, kannst du per "drop procedure Lib.Name" die Prozedur wieder entfernen (auch von STRSQL auf der AS/400).

Welche Prozeduren vorhanden sind, lässt sich über "select * from procedures" erfragen.

[BeWe]

Nicht schlecht, nicht schlecht

genau das wäre meine nächste nervige Frage gewesen ;-).
Allerdings habe ich bei dem ganzen Probieren mehrere
Procedures mit unterschiedlichen Paramterzusammenstellungen
erstellt eine habe ich mit

drop procedure QTEMP/Procname (CHAR)

gelöscht bekommen, aber zwei weitere nicht mehr. Gibt es
dabei so was wie Wildcards?

Delete * from procedures where Procname = "ProcName"
geht leider nicht

Vielen Dank nochmal für die Tips, habe jetzt schon ein paar
Programme erstellen können bei denen 29 Parameter über-
geben werden und es ist doch noch recht schnell.

[Fuerchau]

Welche Proceduren da sind, kannst du ja aus "procedures" erfahren.
Welche Parameter eine Prozedur hat erfährst du aus "Sysparms" !

Proceduren müssen leider genauso wies sie erstellt wurden, gelöscht werden.
Es können ja durchaus gleiche Prozeduren mit unterschiedlichen Parametern erstellt werden. Dies nennt man "Overloading", bekannt aus der C++-Programmierung.

Beim "drop procedure" muss die genaue Parameterliste angegeben werden, im Zweifel sogar die Ausprägung:

drop procedure lib.name (char, char, ...)
drop procedure lib.name (char(10), char(5), ...)

usw.

Das gleiche gibt es übrigens auch für Funktionen "create function".
Vorteil hierbei ist, dass diese Funktionen im "Select" bzw. überall wo Scalar-Funktionen erlaubt sind, verwendet werden können.
Seit V5 kann man sogar reine SQL-Funktionen erstellen, da der intern verwendete C-Kompiler nicht extra lizensiert werden muss.
Ich kann also relativ komfortable Funktionen in SQL erstellen ohne RPG bemühen zu müssen.

[BeWe]

Ja so klappt das anscheinend recht gut , und ich kann
nur abermals tausend Dank aussagen.

In C++ ist das Überladen von Funktionen, mit genügend
Vorsicht ja durchaus eine Interessante Sache. Wusste
bis eben nicht, dass dies auch hier als solches Phänomen
zu verstehen ist.

Aber ganz ehrlich,... habe mal gehört, dass ein gut durch-
dachtest RPG-Programm schneller sei, als SQL. Ist da etwas
dran, oder ist das falsch?

[Fuerchau]

Ja und Nein !
Es gibt 1000+ Argumente, die da eine Rolle spielen.

1. DB-Design
Es gibt Designs, da ist RPG einfach schneller, da SQL damit nicht zurechtkommt (Stichwort Normalisierung). Probleme bieten z.B. Schlüsselungleichheiten (Numerisch/Alpha) bei Join's oder Beziehungen, die nur per Programm aufgelöst werden können.

2. Recordlevel-Access (Einzelsatzverarbeitung)
Hier sollte man bei RPG folgendes wissen:
Dateizugriffe erfolgen immer über interne Puffer, also nie mit den Feldern direkt.
Durch die F-Bestimmung wird ja automatisch eine I-Bestimmung generiert. Der Compiler generiert aber ausschließlich die Felder, die eine Referenz aufweisen.
Nach einem READ/CHAIN werden aus dem Puffer die Felder gefüllt und vor dem WRITE/UPDATE der Puffer aus den Feldern gefüllt.
Arbeitet man aber mit einer externen DS, die alle Felder enthält auch wenn man sie nicht benötigt, werden jede Menge Move's generiert, die nichts als Zeit kosten.

Bei SQL sollte man IMMER die Felder selektieren (und fetchen) die man benötigt, man spart sich da also ein bißschen. Merkbar ist das aber nur bei sehr vielen (>100.000) Datensätzen.

Bei der Feldart sollte man darauf achten, dass nach Möglichkeit der gleiche Typ verwendet wird, das spart Konvertierungen.
Leider kennen DSPF/PRTF's keine gepackten Felder (auch wenn man sie definiert, der Compiler macht immer zoned daraus), was fast immer zu einer Konvertierung führt.

Auch SQL führt Anpassungen durch, die man aber durch explizite Definition minimieren kann.

3. Massen-Funktionen
Ganz klar bietet SQL den Vorteil bei Select mit Gruppierungen, Scalar-Funktionen o.ä.
Hier reicht oftmals ein Select, was in RPG mühsam programmiert und berechnet werden muss. Hier ist SQL schneller, da dies auf sehr tiefer Ebene in der DB gelöst wird.
Auch ein Massen-Update sowie Massen-Delete bietet große Vorteile.

Fazit:
Es kommt immer auf die gewünschte Funktion an, ob SQL oder RPG schneller ist.
Übrigens: COBOL kennt viele Overheads von RPG nicht und ist insbesonders bei nativen Dateizugriffen schneller (hier wird im Programm direkt mit den Dateipuffern gearbeitet).

Ein großer Vorteil von SQL ist, dass ich Optimierungen der DB vornehmen kann, ohne an den Programmen etwas zu ändern (Formatebenen-Id) oder einfach nur Spalten hinzufügen kann.
Ist ein SQL-Zugriff langsam, kann ich ihn beschleunigen indem ich einen Index erstelle. Will ich das RPG-Programm beschleunigen erfordert das ggf. ein Redesign.

[Fuerchau]

Nachtrag

29 Parameter sind ja doch releativ viel, da die Gesamtanzahl Paramter auf (ich glaube) 32 beschränkt ist.
Wenn dies alles Ausgabeparameter sind, bietet sich eine andere, flexiblere Lösung an:

as400db.Execute "CREATE PROCEDURE MyLib.MyPgm (IN :PARM1 CHAR (512), IN :PARM2 DEC(15, 5)) LANGUAGE RPG RESULT SET 1 NOT DETERMINISTIC NO SQL EXTERNAL NAME MyLib.MyPgm PARAMETER STYLE GENERAL", , adExecuteNoRecords

Damit kannst du eine dynamisches Recordset zurückgeben:

h dftactgrp(*no) actgrp('MyGroup')

d MyStruct ds
d Field1 10
d Field2 5
d Field3 10p 2
:

/exec sql set result sets array MyStruct for 1 row
/end-exec

eval *inlr = *off

Wichtig ist, das das Programm aktiv bleiben muss, da auf die Variablen von SQL noch zugegriffen werden muss.

Vorteil:
Die Anzahl der Prozedur-Paramter reduziert sich und bei Erweiterung der Return-Werte braucht die Prozedur nicht neu beschrieben werden.

Die Anzahl der Zeilen kann auch dynamisch festgelegt werden:

d MyCount s 5p 0
d MyStruct ds dim(1000)

/exec sql set result sets array MyStruct for :MyCount row
/end-exec

Anzahl kann natürlich auch 0 sein (leeres Recordset).

Mit "set MyRcd = as400cmd.Execute" wird dann ein Recordset zurückgegeben.

Ich denke, dass dieses Verfahren für Dich vielleicht die bessere Lösung darstellt.

[BeWe]

Hallo Fuerchau,

vielen Dank für den Tip, werde das auf jeden Fall mal versuchen
zu testen, jedoch weiss ich nicht, wie ich in RPG eine Struktur
zurückgeben kann, bzw. wie dann der Parameter definiert werden
muss.

Folgendes Problem hat sich neuerdings ergeben...

D UrProg s 11S 2 DIM(12)

anstatt 12 einzelne Paramter gilt es nun dieses (ich denke mal)
eindimensionale Array zurückzugeben, wobei ich mich frage
welchen Typ für diesen Parameter ich dann bei der CREATE PROCEDURE
angeben soll. Char und Dec doch sicher nicht, oder?

Weisst du da eine Lösung bezüglich dieses Problems?

Nochmals danke für den Tip, und sorry für die späte Antwort.
PS.: lautet der SQL-Code in deinem Beispiel wirklich so, oder ist
das einfach nur englischer Pseudo-Code

[BeWe]

Nachtrag:

** umwandeln mit COMMIT *NONE
** ALWCPYDTA *NO
***********************************************
h dftactgrp(*no) actgrp('MyGroup')
/free
d MyStruct ds
d Field1 10
d Field2 5
d Field3 10S 2
:

/exec sql
set result sets array MyStruct for 1 row
/end-exec

*inlr = *off

/end-free


Habe das Programm so erstellen wollen, wobei ich allerdings
auf mehrere Fehler gestoßen bin. Zum Beispiel einen 40er
Fehler der da heist "Das Umwandlungsprogramm kann nicht
bestimmen wie das Programm enden kann"

Was mache ich falsch? Semikolons vergessen? kommen die
ausnahmslos hinter jede Zeile?

[Fuerchau]

Den Code habe ich aus dem Handbuch "SQL Programming Concepts" entnommen und ist dort in ähnlicher Form zu entnehmen.

Arrays werden von SQL grundsätzlich nicht unterstützt. Hier bietet sich geradezu obige Methode an, da hier im Recordset 12 Sätze zurückgegeben werden können.

Im übrigen frage ich mich hier, was du mit den vielen Prozeduren überhaupt so treibst und du nicht ggf. in konzeptionelle Schwierigkeiten kommst.
Das Design des Ganzen sollte man vielleicht mal etwas detaillierter betrachten. Ich kann auch gerne hierzu Unterstützung leisten (siehe meine Homepage).

[Fuerchau]

"/free" ist nur im C-Teil der Quelle erlaubt.

"/exec sql" ist nicht im Free-Format möglich (daher kein Semikolon) weil der Pre-Compiler Nicht-Free-Formate generiert.

Im Free-Format ist immer ein Semikolon am Ende einer Anweisung erforderlich, da der Compiler sonst nicht weiß wie es weiter geht.

Der Einfachheit halber hatte ich mein Beispiel auch nicht im Free-Format angegeben.

[BeWe]

Aha, ja gut, das muss ich ja auch erst einmal wissen, gell .
Werde das mal gleich probieren...

Zum Konzept... ich arbeite in einem größeren Unternehmen
für welches hier intern Programmlösungen und -Anpassungen
geschrieben werden müssen. Das ganze hat alles auf einer
As400 angefangen wo die Daten auch jetzt noch Dank der
hohen Stabilität bleiben sollen.
Allerdings wollen wir uns etwas von den Scharz-grünen
Bildschirmmasken lösen und suchen daher Alternativen in
anderen Programmiersprachen wie z. B. Visual Basic, wo
ich mich ganz gut auskenne.

Unsere AS400-Programmierer tendieren eher zu Java,
wobei ich finde dass dort alles wesentlich umständlicher
ist, oder liegt das nur in meiner Java-Unwissenheit begründet?

Ich denke gerade im Office - AS400 - Datenaustausch und
überall sonst, wo Microsoft-Produkte eingesetzt werden kommt
man doch sehr, sehr viel schneller mit VB ans Ziel, oder was
kannst du da empfehlen?

[Fuerchau]

Im MS-Office-Bereich ist tatsächlich der bessere Weg VB, VBA. Nach Möglichkeit sollte man Standard-ODBC-Zugriffe verwenden können ohne komplizierte Prozeduraufrufe !
Funktionen im Select (mittels Create Function) machen auch noch Sinn, aber für alles andere muss man ja doch schon programmieren, AddIn's entwickeln usw.

Java ist genauso gut oder schlecht wie VB, kommt auf die Entwicklungsumgebung an.
Bei VB muss ich mich ja auch nicht mehr um alles kümmern, genauso gilt dies für Java.
Der einzige Nachteil bei Java sind die Resourcen:
welche JVM soll laufen (Microsoft, IBM, Sun, ...)
wie schnell ist die Hardware
usw.
Vorteile von Java kann dir Dieter Bender sicherlich genug ausführen.

Tipp's:
Für den Download (Excel, Word-Serienbrief) sollte man die Stand-ODBC-Funktionen (MS-Query) verwenden und nicht die CA-Transfer's (siehe hierzu auch meine anderen Beiträge).
Für den Upload (aus Excel) kann ich mein Tool Upload400 wärmstens empfehlen.