Kann ein SQL Cursor übertragen werden?

[BenderD]

... wieso willst Du da einen cursor übergeben?. Du brauchst doch nur eine exportierte procedure getNextRecord(), die einen kompletten Datensatz zurückgibt. Das ist doch Basisgeschäft von Data Access Modulen. Und was die Performance angeht, die Unterschiede liegen unterhalb der Messbarkeit und bei entsprechender Programmierung (caching und Blockfetch) ist das schneller akls Rekord Löffel.

D*B

[dholtmann]

Genau das versuche ich zu basteln.
Allerdings möchte ich kein setll/read verwenden, da ich nach verschiedenen alten logischen Dateien lesen möchte. Momentan war mein Ansatz den Namen der logischen Datei zu übergeben, dann per dspfd den key zu lesen und diesen in das Order by des SQL zu geben.
So weit so gut. Der erste Satz wird in die DS geschrieben und die Prozedur verlassen.
Jetzt besteht mein Problem darin Satz zwei zu lesen.

[Fuerchau]

Da zäumst du dein Pferd von hinten auf.
Dieser Ansatz ist für SQL grundfalsch.
Befreie dich von der LF-Denke und kümmere dich ausschließlich um den SQL.
Für jede Sortierung legst du halt 2 Funktionen an:
- declare und Open des Cursors
- Fetch next des Cursors und Close am Ende
Dies führt zu statischen SQL's die erheblich performanter sind.
Benötigst du eine neue Sortierung, gibts 2 neue Funktionen.
Fehlt dazu ein Index, dann wird er halt angelegt.

Dein Ansatz führt zu a) dynamischem SQL und b) zu keiner Garantie dass der Index (LF) auch verwendet wird.

[BenderD]

... von Pferden kann man offenkundig unterschiedliche Meinungen haben...
für Deinen Ablauf würde ich dem Serviceprogramm eine procedure setOrderBy geben und eine openCursor. Im Serviceprogramm muss man dann drauf achten, dass das beim CRTSQLMOD kein CLOSSQLCSR(*ENDMOD) drinsteht, damit einem der Cursor nicht geschlossen wird.
Dynamic SQL ist von der Performance keinerlei Problem, Programm technisch auch nicht, letzte Woche habe ich das wieder mal in einem Workshop mit totalen ILE Newbies in den Übungen implementieren lassen.

D*B

PS: lass dich nicht ins Boxhorn jagen, wg. dynamic SQL und so - auf anderen Büchsen greift man immer auf diese Art und Weise mit Zugriffsmodulen auf SQL Datenbanken zu.

[dholtmann]

Dankeschön euch!
Unabhängig von der Lösung habe ich jetzt das Problem, dass mein "declare" scheinbar
keinerlei Beachtung vom Compiler findet.

Vor dem declare kann ich sqlcode beliebig setzen (mit ev im debug).
dann kommt mein Codestück:

         exec sql declare  fieldcursor cursor for
                  select   apkeyf, apkseq
                  from     tmprcdfmt
                  order by apkeyn asc;


         if sqlcode <> 0;
           ind_fehler = *on;
           return ind_fehler;      
         endif;

und mein sqlcode hat danach immernoch den selben Wert, als hätte er nicht
einmal versucht den Cursor zu setzen.
exec sql open xy oder close xy dagegen finden Beachtung.
Habt ihr da eine Idee?

Das Modul erstelle ich so:

CRTSQLRPGI 
             OBJ(TESTLIB/SQLTEST)      
             SRCFILE(TESTLIB/QRPGSRC) 
             SRCMBR(SQLTEST)             
             OBJTYPE(*MODULE)           
             REPLACE(*YES)              
             DBGVIEW(*SOURCE)

[B.Hauser]

Declare ist nur die Beschreibung, wie auf die Daten zugegriffen werden soll.
Eine Aktion erfolgt erst beim Open und bei diesem kann der SQLCODE dann geprüft werden.

Birgitta

[dholtmann]

Das erklärt einiges!
Dann darf ich da den SQLCode einfach noch nicht abfragen.
Perfekt.
Dankeschön!

[dholtmann]

Hallo,
habe jetzt alles hinbekommen.
Meine Prozedur zum Lesen sieht wie folgt aus:

dcl-pi pr_ar_readsql ind;
DS_Input likeds(DS_Datei);
end-pi;
//-----------------------------------------------------------------------
// Variablen
//-----------------------------------------------------------------------
dcl-ds DS_SQL_Out ext extname('AR') end-ds;
dcl-s ind_fehler ind;
dcl-s cha_statement char(500);
//-----------------------------------------------------------------------
// Verarbeitung
//-----------------------------------------------------------------------
ind_fehler = *off;
exec sql fetch cursor_ar into S_SQL_Out;
if sqlcode <> 0;
ind_fehler = *on;
if sqlcode = 100;
exec sql close cursor_ar;
clear ds_input;
endif;
else;
DS_Input = DS_SQL_Out;
endif;

Bei ungefähr 600.000 Sätzen benötige ich ungefähr 38 Sekunden.
Native IO schafft das Ganze in 3-7 Sekunden.
Liegt das am Prozeduraufruf? Oder am Fetch?
Habt ihr Ideen wie das schneller funktioniert?

[Fuerchau]

Da kommt schon einiges an Overhead zusammen.
Zunächst mal die Frage ob du bei Native-IO die Datei als Input oder Update definiert hast?
Beim Input wird geblockt gelesen und dann z.T. nur noch Zeiger versetzt.
Realer Vergleich geht nur mit ungeblocktem Lesen.
Hast du für Native-IO auch den Prozedur-Overhead programmiert?

Und dann schau dir mal die Listauflösung an.
Für SQL wird jede Variable 2 mal deklariert, 1 x SQL-XXX und dann eben Dein Feld.
Der Overhead liegt nun in den vielen Aufrufen und Übergaben und zusätzlichen Moves begründet.

[dholtmann]

Stimmt, der Aufruf klaut Einiges.
Wenn ich innerhalb der Prozedur alle Sätze fetche sind es noch 11Sekunden.

Die Grundidee war jedoch das read auf die Logische auszulagern, um alle Dateizugriffe zentral nur noch über ein Prozedur statt aus Programmen zu steuern.
Wenn es in Summe so viel Zeit kostet kann ich das bloß leider nicht nutzen.

[BenderD]

... gute 15.00 pro sec. sind doch ein guter Wert, was hast Du denn wirklich vor?

D*B

Hallo,
habe jetzt alles hinbekommen.
Meine Prozedur zum Lesen sieht wie folgt aus:


Bei ungefähr 600.000 Sätzen benötige ich ungefähr 38 Sekunden.
Native IO schafft das Ganze in 3-7 Sekunden.
Liegt das am Prozeduraufruf? Oder am Fetch?
Habt ihr Ideen wie das schneller funktioniert?

[dholtmann]

Nunja bisher laufen sämtliche Programme auf Logischen.
Egal, ob 1 Satz gelesen wird oder 25 Millionen.
Für zukünftige Programme wollte ich das halt generell auf diese Art auslagern.
Wenn ein Programm jetzt im Extremfall schon 2 Stunden läuft, habe ich einfach die
Befürchtung, dass es durch das vielfach langsame Lesen in Summe zu erheblichen Verzögerungen kommt.