SQL UDTF mit externem RPG-Programm?

[cbe]

Hallo,

ich brüte und verzweifle gerade über dem Problem, dass ich abh. von div. Parametern Daten an ein externes System zurückliefern will.

UDTFs scheinen mir da genau das richtige zu sein, aber wie definiere ich das?

Der grundsätzliche Aufbau ist doch
create function fkt (x char 1)
returns table (
y1 char 1, y2 char 1)
external name 'RPGPGM'
language rpgle
oder?

Wie komme ich an die Werte des RPG-Programms? Muss das mit jedem Aufruf 1 Zeile liefern?
Oder geht das überhaupt?
Vielleicht hat jemand ein Beispielprogramm?

Bin für jeden Tip dankbar!

Gruß
Christian

[BenderD]

Hallo,

UDTF geht am einfachsten in SQL, beschrieben ist das in der SQL Reference und es gibt da ein Redbook http://www.redbooks.ibm.com/redbooks/pdfs/sg246393.pdf
.... aber, ob das vielleicht nur die zweitbeste Lösing ist, die Dinger können Grottenlangsam sein, insbesondere bei großen Datenmengen, wenn das in einer normalen View geht, ist das wesentlich schneller, da müsste man die Anforderung genauer kennen.

mfg

Dieter Bender

Hallo,

ich brüte und verzweifle gerade über dem Problem, dass ich abh. von div. Parametern Daten an ein externes System zurückliefern will.

UDTFs scheinen mir da genau das richtige zu sein, aber wie definiere ich das?

Der grundsätzliche Aufbau ist doch
create function fkt (x char 1)
returns table (
y1 char 1, y2 char 1)
external name 'RPGPGM'
language rpgle
oder?

Wie komme ich an die Werte des RPG-Programms? Muss das mit jedem Aufruf 1 Zeile liefern?
Oder geht das überhaupt?
Vielleicht hat jemand ein Beispielprogramm?

Bin für jeden Tip dankbar!

Gruß
Christian

[cbe]

Hallo Dieter,

danke für die Antwort.
Ja, eine UDTF in SQL ist einfach - aber wie Du sagst, in meinem Fall viel zu langsam.
Es ist eine rel. große Datenmenge natürlich mehrstufig über div. Tabellen, die aber durch Parameter eingeschränkt wird, so dass i.d.R. höchstens ein paar hundert Sätze geliefert werden.

Die Logik ist komplex genug, dass ein RPG Sinn macht, nur wie bekomme ich die Ergebniszeilen in die SQL-Funktion?

[Fuerchau]

SET RESULT SETS
The SET RESULT SETS statement identifies one or more result sets that can be returned from a
procedure when the procedure is called by a Client Access client, the SQL Call Level Interface, or when
access from a remote system using DRDA.
Invocation
This statement can only be embedded in an application program. It is an executable statement that cannot
be dynamically prepared. It is not allowed in a REXX procedure.
Authorization
None required.
Syntax
 SET RESULT SETS
,
ARRAY host-structure-array FOR host-variable ROWS
CURSOR cursor-name
NONE

Description
CURSOR cursor-name
Identifies a cursor to be used to define a result set that can be returned from a procedure. The
cursor-name must identify a declared cursor as explained in “Description” on page 375 for the
DECLARE CURSOR statement. When the SET RESULT SETS statement is executed, the cursor
must be in the open state.
ARRAY host-structure-array
host-structure-array identifies an array of host structures defined in accordance with the rules for
declaring host structures. The array cannot contain a C NUL-terminated host variable.
The first structure in the array corresponds to the first row of the result set, the second structure in the
array corresponds to the second row of the result set, and so on. In addition, the first value in the row
corresponds to the first item in the structure, the second value in the row corresponds to the second
item in the structure, and so on.
LOBs cannot be returned in an array when using DRDA.
Only one array can be specified in a SET RESULT SETS statement.
FOR host-variable ROWS
Specifies the number of rows in the result set. The host-variable must be a numeric host variable with
zero scale, and it must not include an indicator variable. The number of rows specified must be in the
range of 0 to 32767 and must be less than or equal to the dimension of the host structure array.
NONE
Specifies that no result sets will be returned. Cursors left open when the procedure ends will not be
returned.

[BenderD]

Hallo,

ich bin mir nicht sicher, dass die Geschwindigkeit am SQL liegt, da wird letztlich auch nur embedded SQL in C generiert, nach meinen Beobachtungen lag das bei mir an der Erstellung einer Temp Table, was je nach Satzanzahl recht langsam und wenn man das dann weiter joined (bei der famosen neuen Query Engine) in die Katastrophe führt.

mfg

Dieter Bender

Hallo Dieter,

danke für die Antwort.
Ja, eine UDTF in SQL ist einfach - aber wie Du sagst, in meinem Fall viel zu langsam.
Es ist eine rel. große Datenmenge natürlich mehrstufig über div. Tabellen, die aber durch Parameter eingeschränkt wird, so dass i.d.R. höchstens ein paar hundert Sätze geliefert werden.

Die Logik ist komplex genug, dass ein RPG Sinn macht, nur wie bekomme ich die Ergebniszeilen in die SQL-Funktion?

[cbe]

set result sets ist genau der Tip, den ich brauchte - vielen Dank, der Feiertag ist gerettet...
An den Details muss ich noch feilen, bis es funktioniert, aber der Weg sieht gut aus!

@Dieter: Das ganze hatte ich schon als SQL-Variante probiert, aber mit den Parametern, die wenn sie belegt sind die Liste einschränken kam ich auf unerträgliche Laufzeiten.

Gruß + schönen Feiertag
Christian