SQL :mehrere felder in einen string

[Robi]

Hi,
ich würd gern mit einem ILE RPG SQL Pgm Felder aus einer Datei lesen. die Felder und die Datei such ich mir erst zur Laufzeit zusammen.

Das eEgebniss sollte ein Sting sein.

ungefär so:
eval sql_sel = 'select ' + feld1 + 'concat' + feld2 + 'concat' + feld3 ... 'as string from ' + datei

prepare ...
und
fetch next into :mystring

Das Problem: 1. das Casting von numerischen Feldern
(kein echtes problem, nur 'unschön')
2. gepackte felder dürfen NICHT entpack werden
geht das irgendwie ?

select record as string o.ä. ?

danke Robi

[Fuerchau]

Das geht voll in die Richtung dynamisches SQL.
Sauber wäre das mit SQLDA und FETCH using :MySqlda, aber das sprengt hier den Rahmen.

Was du vorhast geht natürlich, aber gepackte Felder können dann nur entpackt werden. Wenn du Vorzeichen und Komma benötigst, must du mit "char(mynum)" casten ansonsten reicht auch "digits(mynum)". Im Programm musst du ggf. mittels %dec() wirder zurückwandeln.

Ansonsten geht das so wie du dir das vorstellst.

Prepare...
Open ...
Fetch ...
Close ...

[kuempi von stein]

weiss nicht ob ich das richtig verstanden habe....

aber um gepackte felder auch gepackt darstellen zu können müsste man doch nur ne logische file rüberlegen in der da wo das gepackte feld als *char definiert ist?
und dann mit der logischen arbeiten?

macht für mich zwar wenig sinn aber wers braucht...

und falls ich das jetzt falsch verstanden habe einfach mein posting ignorieren...

so long

k.

[Fuerchau]

@Kuempi
Das mit der LF geht so nicht, da numerische Felder dann nur als Zoned gewandelt werden können.
Ausserdem soll das hier ja voll dynamisch gehen (wie immer die Daten später auseinandergenommen werden:

select feld1 concat char(feld2) concat ... from myfile where ...

[Robi]

Danke erstmal,

Kurz als Erklärung:
Auseinandergenommen wird der String von Standartprogrammen die die Felder in einem Subfile darstellen.
(wir haben nur 1 Subfile, das über Leseprogramme und einen Satzstring jede Datei in beliebiger Feldfolge anzeigt.) Ziel ist es nun, die individuellen Lesepgmme je Datei abzuschaffen und eine Dynamische Lösung zu kreieren und dann auch VIEW 's zu können.

@Fuerchau: hast du einen Link zu einem Bsp. in SQLDA ?
Mr Google kennt nur oracle


Danke Robi

[BenderD]

hallo,

das könnte Probleme geben, weil du dann nur noch einen Cursor hast, statt mehrere; sprich das lesen eines Kunden stört das sequentielle lesen der Aufträge.

mfg

Dieter Bender

Danke erstmal,

Kurz als Erklärung:
Auseinandergenommen wird der String von Standartprogrammen die die Felder in einem Subfile darstellen.
(wir haben nur 1 Subfile, das über Leseprogramme und einen Satzstring jede Datei in beliebiger Feldfolge anzeigt.) Ziel ist es nun, die individuellen Lesepgmme je Datei abzuschaffen und eine Dynamische Lösung zu kreieren und dann auch VIEW 's zu können.

@Fuerchau: hast du einen Link zu einem Bsp. in SQLDA ?
Mr Google kennt nur oracle


Danke Robi

[Robi]

Das ist bedacht,
max. 5 cursor in einem job, werden mehr gebraucht wird eine neue actgrp geöffnet. Passiert das zu oft, wird auf 10 cursor erhöht.( das pgm wird angepasst)
Robi

[Fuerchau]

Schau mal unter folgendem:
http://publib.boulder.ibm.com/iserie....htm#HDRDYNMIC

Das Hauptproblem ist wohl das zur Verfügung stellen von Speicher für die Variablen bzw Gesamtpuffern, es sei denn man arbeitet immer mit festen Größen.
Auch die Übergabe der Daten an ein anderes Programm ist dann nicht so einfach, da es ja "beschreibende" Strukturen geben muss.

Ausserdem geht das Ganze eigentlich in die falsche Richtung.
Um performant mit den Daten zu arbeiten sind statische SQL's einfach besser.
Ausserdem schleppt man einen geringeren Overhead mit sich herum.
Zusätzliche Schnittstellendefinitionen, Castings um die Daten zu verarbeiten, und und und ...

Ich würde mir da eher noch mal Gedanken zum Konzept machen.
Das Abschaffen der Filehandler-PGM'e hat insoweit noch Konsequenzen, da nach deiner Methode nur noch 1 Abfrage überhaupt möglich ist.
Oder du benötigst je möglicher paralleler Abfrage ein Programm bzw. Modul, da ein Cursor nicht dynamisch definiert werden kann.
Da aber durchaus mal mehr als 20 oder 50 Dateien auf sein können, hast du ein Problem.

Wie siehts denn überhaupt mit den Schnittstellen aus ?
Dein Konzept bedeutet ja, das das dynamische Programm als Unterprogramm/Servicemodul fungiert. Es kann also innerhalb des Lebenszyklusses durchaus von verschiedenen Programmen aufgerufen werden. Bedenke das mal bei deinem Redesign !

Die Alternative ist dann noch CLI, eine ODBC-ähnliche Schnittstelle mit jeder Menge C-Funktionen. Mit dieser kannst du dann tatsächlich voll dynamisch SQL's verwalten.
Beliebig viele Statments, Cursors usw., was obige Probleme sicherlich lösen kann aber nicht einfacher macht.

[Robi]

Danke, ich werde den link mal verfolgen.

zu deinen anmerkungen: Absatz 1: mal sehen was der link mir sagt.
Absatz 2: Falsche richtung.. Kann sein, ist aber einen versuch wert(die meisten 'falschen richtungen' die bei uns laufen sind überaus brauchbar und vertretbar schnell)

absatz 3: ... gedanken zum Konzept... ist bedacht: mehrere cursor in abhängigkeit von der Datei die zu lesen ist( zunächst 5 vorgesehen, aber erweiterbar) recall des pgm's über 5 cl's die in benannten actgrp's laufen, verwaltung in der 1. ebene.

Absatz 4 siehe 3
Absatz 5 Ok, werd ich als alternative prüfen

das ganze ist ein 'versuchsballon', wenn's nicht klappt werden wir (wie bisher) dynamische (satzauswahl, sortfolge) statische (Datei, felder) sql-pgmme generieren und dies auch für 'view-lesen' machen
Vielen Dank und schöne Ostertage

Robi

[Fuerchau]

Naja, wenn ich bedenke was das aufrufende Programm so alles an Parametern zu übergeben hat (Datei, Feldliste, Sortierung, Auswahl ...) ...
Wie siehts mit Update/Delete/Insert aus ...

Gerade die Satzauswahl ist bei dynamischem SQL arg langsam wenn die Where-Bedingung immer zusammengebaut werden muss (Feldtypen, Zeichenketten mit Hochkomma, Datumfelder...). Parameter-Abfragen sind da auch erheblich schneller.

Die Fehlersuche wird dann auch nicht gerade leichter !

[Robi]

Diese Programm dienen nur dem lesen!!
Die (z.zt. über einen eigenen Generator erzeugten Pgmme)
lesen die Satzauswahl und die Sortfolge, bauen sie zusammen und sind mehr als schnell genug, verglichen mit (setll, read, Satzauswahl und ok oder neu lesen)Der Vorteil : Die Satzauswahl und die Sortfolge bestimmt der Kunde.
Wir programieren seit mehr als 5 jahren keine satzauswahl mehr, es sei denn Sie extrem exotisch. aber auch eine 'händisch programmierte' wird von der Automatik erkannt und durchgeführt.

Da alles von einer sehr gut getesteten Mutter generiert wird, werden diese pgmme mittlerweile 'Debugunfähig' ausgeliefert.
Die Rahmenbedingungen für das o.a. Projekt haben wir also. Mit dem link komme ich auch weiter, werde am dienstag fertig sein. Dann gehts in die Performancetests.
Bei interesse: einfach mal bei uns reinschauen
Mail an mich
Sitz: Hannover

Robi