SQL :mehrere felder in einen string

[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