View Full Version : SQL: Select nicht seitenweise ausführen
Hallo zusammen,
eine select-Anweisung wird ja immer(?) seitenweise ausgeführt bzw. beim Vorwärtsblättern bzw. -scrollen wird weiter gelesen.
Im STRSQL ist das eine Bildschirmseite, im ACS-SQL-Skript-Editor sind das 102 Sätze, die selektiert werden. Dann muss jeweils geblättert bzw. gescrollt werden.
Kann ich irgendwie steuern, dass der Select gleich bis zum Ende durchgeführt wird?
Hintergrund: im Select führe ich eine Funktion, die nicht nur ein Ergebnis zurückliefert, sondern auch noch weitere Daten schreibt bzw. Anweisungen erledigt.
Da mein Select 792 Sätze findet, sprich die Funktion 792 mal ausgeführt werden soll, ist es nervig, wenn ich immer bis zum Ende blättern oder scrollen muss, bis alles erledigt ist.
Noch schlimmer: dieser Select ist eine Anweisung eines SQL-Skript. Die Anweisungen dieses Skripts möchte ich alle nacheinander im ACS-Skript-Editor ausführen. Dann funktioniert es gar nicht.
Hat jemand eine Idee?
Aktuell gibt es keinen Button oder Funktionstaste oder sonstigen Befehl durch den erzwungen werden kann, dass bei einem SELECT-Statement alle Datensätze gelesen werden.
Schreib' dir eine Stored Procedure oder führe eine dynamsiche Prozedur (BEGIN ... END - und dazwischen SQL-Befehle), in der ein Cursor definiert wird, über den das SQL-Statement komplett verarbeitet wird. Damit sollten dann Deine Funktionen alle ausgeführt werden.
... warum führst Du ein Skript aus, anstatt den completten SQL Code in eine Stored Procedure zu packen und diese dann auszuführen. Dann kannst Du auch Deinen SELECT sauber verarbeiten.
... im übrigen ist es keine besonders gute Idee Updates in UDFs auszuführen.
Birgitta
KingofKning
27-11-19, 12:12
Ein select count(*) hilft nicht?
... im übrigen ist es keine besonders gute Idee Updates in UDFs auszuführen.
Tja, hätte ich eine Schulung in SQL gehabt würde ich soetwas auch nicht machen. Aber für meine Sachen benutze ich das auch, weil schneller als ein Cobol Programm zu schreiben.
GG 4203
danke für Euren zahlreichen Tips.
"im übrigen ist es keine besonders gute Idee Updates in UDFs auszuführen."
-> Tatsächlich mache ich keinen Update in der UDF, sondern einen create table sowie einen insert in eine Log-Datei. Ich erstelle also mit meiner Select Anweisung 792 Tabellen und protokolliere die Create Table-Anweisung in einer Log-File.
"warum führst Du ein Skript aus?" -> weil ich im ACS-SQL-Skript-Editor schön den Fortschritt beim Abarbeiten der einzelnen Schritte sehe. Oder bei Bedarf kann ich zum Testen auch nur einen oder 3 oder 5 Schritte ausführen. Tolle Funktionalität im ACS :-)
"Ein select count(*) hilft nicht?" -> leider nein, da ich Felder der Tabelle, auf die der Select geht, an die Funktion weiterreiche
"Schreib' dir eine Stored Procedure oder führe eine dynamsiche Prozedur (BEGIN ... END - und dazwischen SQL-Befehle), in der ein Cursor definiert wird, über den das SQL-Statement komplett verarbeitet wird. Damit sollten dann Deine Funktionen alle ausgeführt werden."
-> den Cursor lese ich dann per Fetch?
Ja! Du verarbeitest einen ganz normalen Cursor:
DECLARE, OPEN, FETCH, CLOSE
danke für Euren zahlreichen Tips.
"im übrigen ist es keine besonders gute Idee Updates in UDFs auszuführen."
-> Tatsächlich mache ich keinen Update in der UDF, sondern einen create table sowie einen insert in eine Log-Datei. Ich erstelle also mit meiner Select Anweisung 792 Tabellen und protokolliere die Create Table-Anweisung in einer Log-File.
"warum führst Du ein Skript aus?" -> weil ich im ACS-SQL-Skript-Editor schön den Fortschritt beim Abarbeiten der einzelnen Schritte sehe. Oder bei Bedarf kann ich zum Testen auch nur einen oder 3 oder 5 Schritte ausführen. Tolle Funktionalität im ACS :-)
"Ein select count(*) hilft nicht?" -> leider nein, da ich Felder der Tabelle, auf die der Select geht, an die Funktion weiterreiche
"Schreib' dir eine Stored Procedure oder führe eine dynamsiche Prozedur (BEGIN ... END - und dazwischen SQL-Befehle), in der ein Cursor definiert wird, über den das SQL-Statement komplett verarbeitet wird. Damit sollten dann Deine Funktionen alle ausgeführt werden."
-> den Cursor lese ich dann per Fetch?
... eigentlich brauchst Du da keinen Fetch. Sieh Dir mal das Beispiel in der SQL Reference an:
BEGIN
DECLARE fullname CHAR(40);
FOR vl AS
c1 CURSOR FOR
SELECT firstnme, midinit, lastname FROM employee
DO
SET fullname =
lastname || ', ' || firstnme ||' ' || midinit;
INSERT INTO TNAMES VALUES ( fullname );
END FOR;
END;
Aufpassen must Du mit dem error Handling, das ist etwas hakelig. Ohne Continue Handler düst du da unversehens aus der Stored procedure raus.
D*B
Das "Blocken" kommt aus der Connection-Eigenschaft des jeweiligen Treibers (außer dem lokalen). Hier kann man die Blocksize erhöhen um die Anzahl Sätze je Block zu vergrößern.
Deshalb sind es bei kurzen Sätzen mehr Zeilen als bei langen Sätzen.