ODBC DB2/DB400 SQLSetPos

[BenderD]

das ist hier so wie im richtigen Leben, das Problem sitzt meistens vor dem Bildschirm. Wenn jemand eine relationale Datenbank hat und die für sequentielle Haufen und bestenfalls index sequentielle Verarbeitung und andere Formen der Datenkompostierung benutzt und das auch noch für das größte hält, dann hat er halt keine primary Keys, keine referential constraints, verarbeitet Datenbanken mit Bibliotheks Suchliste, legt Member an, öffnet Dateien mit share(*yes) und freut sich über jeden OVRDBF mit dem er andere Programmierer und sich selber narren kann.
Die Unterschiede liegen da weniger an der Plattform, sondern siehe oben!
D*B

Aha! So ist das!
Tja, wie man merkt, bin ich mit den DB400 Definitionen
(noch) nicht sehr vertraut.
Da die Funktion SQLPrimaryKeys implementiert ist,
bin ich gar nicht auf die Idee gekommen, dass es
für PFs so nicht gehen kann.
Danke für den Hinweis +lg
Chris

[caltmann]

Hallo!

Ich muss leider noch einmal auf einen angeführten Punkt
zurückkommen.

[...]
>Mit einer eigenen Anweisungen
>
>update mytable set field=...
>where current of cursor-name
>
>kann dann dieser gesperrte Satz geändert bzw. mit
>
>delete from mytable
>where current of cursor-name
>
>gelöscht werden.
[...]


Genau das bekomme ich über ODBC irgendwie nicht hin.
Ich habe mir den Cursornamen ausgelesen, jedoch
kein Erfolg.
Ich nehme an, dass ich da etwas falsch verstanden habe,
vielleicht läßt sich das ja ganz einfach aufklären.

Details z.B. :
- Statement 1 (SELECT * FROM...WHERE id=1 FOR UPDATE)
- dann hole ich mir den Cursornamen
(SQL_CUR020F74F0) mittels
'SQLGetCursorName' von Statement 1
- dann baue ich Statement 2 auf:
DELETE FROM MyTable WHERE CURRENT OF
SQL_CUR020F74F0
So dachte ich mir, sollte es als "SetPos"-Ersatz ja gehen,
tut es aber nicht.
Er meckert, dass der Cursor von Statement 1
nicht geöffnet ist.
"SQL0507 - Cursor SQL_CUR020F74F0 nicht geöffnet. (-507)"

Wie ist das jetzt zu interpretieren, der Cursor muss ja offen
sein, sonst gibt es ja gar keine Daten, oder?
Freigegeben habe ich ihn ja auch noch nicht.
Die Statement (Cursor)-Parameter sehen ok aus,
also nicht "read-only" oder so.

Vielleicht weiß ja jemand etwas näher Bescheid,
was hier schiefläuft. Offensichtlich habe ich hier einen
Verständnis/Denkfehler.

Danke für Infos/Links/Tipps
lg
Chris

[Fuerchau]

Möglicherweise wird das von ODBC nicht unterstützt sondern nur von embedded SQL.
Ggf. ist der Cursor trotz for update readonly.

SQL-Like ist aber ein eigener Update ... where key ... oder ein delete ... where key ...

Das funktioniert mit jeder DB.

[caltmann]

Hhmmm.. Schade.. aber ok, nachdem es jetzt sowieso
ein eigenes Statement ist, werd' ich die "where key"-Thematik
wohl so implementieren müssen.

Danke + lg
Chris

-------------------------------
!!UPDATE!!

nach einigem Hin und Her habe ich das Ganze einmal auf einer DB2-Express
ausprobiert, welche mir die auf der DB400 erfolgreich durchgeführten
Schritte plötzlich mit unterschiedlichen Fehlern quittierte.
Nach Überarbeitung des Ablaufs geht es jetzt auch mit der DB400.
Es klappt also, nur die Fehlermeldungen der jeweiligen Datenbanken
sind oftmals irrführend oder wenig aussagekräftig.

lg
Chris

[Fuerchau]

Nunja, SQLSTATE ist eigentlich als Fehlerschlüssel durch ANSI definiert.
Leider reagieren viele Datenbanken eben unterschiedlich.

Wesentlich bei der DB400 ist, dass ohne Journalisierung gearbeitet werden kann, was fast keine andere DB erlaubt.
Die wesentlichen Fehler daraus sind bei Update/Delete/Insert, dass diese anderen DB's Transaktionen mit Commit/Rollback erfordern.

Es gibt leider keinen Status, ob eine DB400-Tabelle aufgezeichnet wird oder nicht. Hier hilft nur Try and Error.
Klappt der Update z.B. nicht mit dem Fehler "SQL-Journalisierung" versucht man es dann eben ohne Commt.