nicht angemeldet
Neee, das meinte ich nicht. Ich meinte ja, wie ich am sinnvollsten auf die Ergebnismenge zugreife, _nachdem_ ich den Select gemacht habe. Da habe ich halt nur die Funktionen gefunden, nix anderes.
Am schönsten wäre es halt, wenn die einzelnen Felder auf Variablen gemappt wären...
Werden sie ja auch - aber ggf. nicht so, wie Du Dir das vorstellst.
Bei meiner Oracle-Datenbank -nur zum Vergleich - lese ich Daten mit einem C-Programm mit embedded SQL-Anweisungen.
Das Zugriffskonzept dabei ist ein sogenannter cursor, aus dem man pro Zugriff mit einer "fetch"-Funktion einen oder mehrere Datensätze herausholen kann. Ist der cursor "skalar", dann holt man einzelne Datensätze, bis es nicht mehr geht; ist er vektoriell, dann holt man mit einem Zugriff gleich eine ganze Menge von Datensätzen (und erhält einen speziellen Fehlercode, wenn der letzte Cursor nicht mehr voll war, und die Angabe, wie voll er war), die man dann in einer Schleife abarbeiten kann.
Syntaktisch sieht das (ungefähr, genaue Syntax habe ich nicht im Kopf) so aus:
a) statisch definieren:
define cursor testcursor as
select a, b, c
from table_name
into :hostvar_a, :hostvar_b, :hostvar_c;
b) abholen:
fetch from testcursor;
Danach stehen entsprechend viele Werte in den Variablen hostvar_a bis hostvar_c (den Doppelpunkt braucht nur der SQL-Präprozessor, um Client- und Servernamen zu unterscheiden), und die kann ich normal bearbeiten.
Große Cursor brauchen natürlich mehr Speicherplatz, aber sie machen die Sache *viel* schneller, weil nicht für jeden Datensatz die ganze SQL-Interpretation durchlaufen werden muß.
Ich hatte mal aus einer Tabelle mit 15 Mio. Datensätzen möglichst schnell viele Teilmengen zu je ca. 5000 Stück herauszuholen, und durch einen Cursor der Größe 500 Einträge wurde die Sache um Faktor 7 schneller.