embedded SQL, Satz geschützt

[loeweadolf]

[/PHP]
In einem RPG-Programm mit embedded SQL verwende ich
eine Datei, die abwechselnd mit 2 SQL-Cursor
verarbeitet wird.

Mit dem 1. Cursor lese ich bestimmte Sätze aus der
Datei mit declare Cursor1
open Cursor1
fetch Cursor1
....
close Cursor1
Mit dem 2. Cursor lese ich Sätze und lösche einige davon
declare Cursor2
open Cursor2
fetch Cursor2
delete from myDatei where current of
Cursor2

Die beiden Cursor nicht nicht gleichzeitig geöffent.

Beim Löschen kommt der SQL-Code -906 mit dem Text:
Cursor Cursor2 für Datei myDatei schreibgeschützt.

Was muss ich beachten, damit es klappt ?
[PHP]

mfg Ludger

[B.Hauser]

Hallo,

Nur so eine Idee:
wenn Du im Declare-Statement des ersten Cursors am Ende FOR READ ONLY (oder FOR FETCH ONLY) hinzufügst, stellst Du sicher, dass dieser Cursor nur als INPUT ONLY verarbeitet wird. werden

C/EXEC SQL
C+  DECLARE Cursor ....
C+     SELECT ....
C+ FOR READ ONLY 

Der zweite Cursor sollte als SCROLL CURSOR definiert sein.

Wenn das nicht helfen sollte, müsste man das SELECT-Statement des zweiten Cursors sehen. Vielleicht ist der zweite Cursor aus irgendeinem Grund nicht "deletable".

Birgitta

[loeweadolf]

Hallo Brigitta,

nachdem der Stromausfall beseitigt war und der Schnee weggeräumt ist, hatte ich Gelegenheit, Deine Anregung zu testen. Leider hat es nicht geklappt.

Nachstehend nun das Declare des 2. Cursors, bei dem der DELETE nicht klappt.

  
 *============================================ 
 C     de_bolvsn_02  begsr                                          
 c/exec sql                                                         
 c+  declare C_bolvsn_02 cursor for                                 
 c+        select  *                                                
 c+                from  bolvsnpf                                   
 c+                where bvlfsnr = :cpkomm                          
 c+                  and bvauftr = :cpauft                          
 c+                  and bvposit = :cpapos                          
 c+                order by  bvlfsnr, bvauftr, bvposit, bvstcknr    
 c/end-exec                                                         
 C                   endsr 

Vielleicht kannst Du daraus was erkennen ?!

Wenn nicht, dann werde ich das SQL aus dem programm rausnehmen und wieder mit der Native-RPG-Methode arbeiten.

mfg. Ludger

[B.Hauser]

Hallo Ludger,

Cursor, die eine ORDER BY-Anweisung enthalten, sind weder "deleteable" noch "updateable".

Für den Update kann man sich durch das Hinzufügen von FOR UPDATE OF Feld1, ... Feldn behelfen. Für Delete funktioniert dies nicht.

Wenn der ORDER BY nicht unbedingt erforderlich ist, dann lass ihn weg. In diesem Fall kann der Satz über DELETE ... WHERE CURRENT OF gelöscht werden.

Sollte der ORDER BY erforderlich sein, muss der Satz über ein separates SQL-Update-Statement (ohne Bezug auf den Cursor) gelöscht werden. Vorsicht: wenn über relative Satz-Nr. gelöscht werden sollte, wird immer ein Table Scan ausgeführt.

Der Update kann allerdings auch über native I/O ausgeführt weden.

Birgitta

[loeweadolf]

Vielen Dank für die Untestützung und noch ein schönes
Restwochenende.

mfg Ludger

[BenderD]

Hallo,

das halte ich für ein Gerücht, mit for update Klausel und dynamic scroll geht alles (außer Schmuddel wie Key update); order by ist da kein Hinderungsgrund und positioned delete/update aus Performance Gründen immer vorzuziehen.

mfg

Dieter Bender

Hallo Ludger,

Cursor, die eine ORDER BY-Anweisung enthalten, sind weder "deleteable" noch "updateable".

Für den Update kann man sich durch das Hinzufügen von FOR UPDATE OF Feld1, ... Feldn behelfen. Für Delete funktioniert dies nicht.

Wenn der ORDER BY nicht unbedingt erforderlich ist, dann lass ihn weg. In diesem Fall kann der Satz über DELETE ... WHERE CURRENT OF gelöscht werden.

Sollte der ORDER BY erforderlich sein, muss der Satz über ein separates SQL-Update-Statement (ohne Bezug auf den Cursor) gelöscht werden. Vorsicht: wenn über relative Satz-Nr. gelöscht werden sollte, wird immer ein Table Scan ausgeführt.

Der Update kann allerdings auch über native I/O ausgeführt weden.

Birgitta

[loeweadolf]

Hallo Dieter, nachdem ich das where current of rausgenommen hatte und ausserdem
noch eine Dateierweiterung vorgenomme hatte, um den Satz eindeutig bestimmen
zu können, hat es mit dem Löschen funktioniert.
Was nutzen die schönsten Performance-Zeiten, wenn es nicht geht ?

mfg. Ludger

[B.Hauser]

Hallo,
das halte ich für ein Gerücht!

Hallo Dieter,

Hast Du's ausprobiert?
Ich schon!

Wenn ORDER BY angegeben ist, erhält man nach dem DELETE den SQL-Code -510, unabhängig davon ob DYNAMIC SCROLL CURSOR, SCROLL CURSOR oder nur CURSOR angegeben ist.

Steht übrigens auch so in der SQL-Reference, vielleicht nicht ganz so einfach (doppelt verneint und so!)

Birgitta

[Fuerchau]

Laut Handbuch muss der Cursor als "for update" deklariert werden. Dann spielt Order By bzw. der Cursor-Typ keine Rolle.
Allerdings sind Join's in solchen Fällen nicht möglich.

[BenderD]

Hallo,

nicht nur probiert, das ist tägliche Praxis.
Wenn der update geht, dann geht auch der Delete und die ominöse -510 beschreibt, was zu tun ist. Wenn order By, dann ist for update of Klausel erforderlich und die Angabe eines Feldes genügt (kein ORDER BY Feld, kein primary Key). Wenn scroll, dann dynamic und die üblichen Bedingungen für updatable Cursor müssen ebenfalls stimmen.

mfg

Dieter Bender

Hallo Dieter,

Hast Du's ausprobiert?
Ich schon!

Wenn ORDER BY angegeben ist, erhält man nach dem DELETE den SQL-Code -510, unabhängig davon ob DYNAMIC SCROLL CURSOR, SCROLL CURSOR oder nur CURSOR angegeben ist.

Steht übrigens auch so in der SQL-Reference, vielleicht nicht ganz so einfach (doppelt verneint und so!)

Birgitta