ODBC DB2/DB400 SQLSetPos

[Fuerchau]

Nach einiger Überlegung ist mir nun klar, was du willst.
So gehts mit der DB2/400 leider nicht.
Du kannst über ODBC nur das ausführen, was mit SQL auch unterstützt wird:

select ...
for update [of column-name, ...]

Mittels "for update" wird der Cursor updatefähig (ggf. auf Spalten beschränkt). Dies führt dann dazu, dass jeder Satz beim Lesen gesperrt wird (ggf. mit Satzwartezeit und Abbruchmeldung).

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.

Den Cursornamen kannst du ggf. über Statementinfos auslesen.

SQLSetPos wird leider nicht unterstützt.

[caltmann]

Alles klar!
Danke für die verständliche Aufklärung, dann brauch ich die restlichen Seiten nicht durchzuwühlen, zumindest nicht für dieses Thema.
Ich werde die Logik dann wohl entsprechend umbauen.
Danke + lg
Chris

[caltmann]

Hallo!

Das Thema ODBC Unterschiede DB2/DB400 ist ja scheinbar
unerschöpflich. Ich versuche gerade mittels
'SQLPrimaryKeys' die Schlüsselfelder einer Tabelle auszulesen.
Das klappt wieder einmal unter DB2, jedoch nicht mittels "iSeries Access ODBC" auf die DB400. In dem Referenz-PDF für iSeries Access ist die Funktion aber aufgeführt, es kommt auch die Statusmeldung, dass alles ok ist, aber eben keine
Daten (SQLCODE:100). Muss bei der Parameterübergabe
für iA-ODBC irgendeine Besonderheit beachtet werden?
Ich habe schon eine Menge Optionen ausprobiert und die
3 Parameter (Catalog, Schema, Table) unterschiedlichst befüllt. (z.B. SERVER,OWNER,LIB.TABLE oder
LIB, OWNER,TABLE).
Hat aber leider nicht geklappt.
Kann es an der iSeries-Version (V4R5) liegen?
Wenn ja, müsste aber dann nicht ein anderer Fehler kommen?
Das lokale ODBC-Log sieht ok aus, ich vermute irgendeine Kleinigkeit bei der Parameterübergabe, da bei unsinnigen
Tabellennamen die gleiche Reaktion passiert.
Bei SELECT * FROM MY_BIB.MYTABLE wird auch der Punkt verwendet. Darf das bei SQLPrimaryKeys vielleicht
nicht so sein?

Danke für Infos/Tipps/weiterführende Links
Chris

[Fuerchau]

Wenn die Tabelle als normale PF per DDS definiert ist, gibt es keine PrimaryKeys!

Primary Keys können nur per SQL definiert werden:

alter table mytable
constraint MyTablePrimary PRIMARY KEY (Column1, ...)

Alle anderen Indexe können nur per SQLStatistics ermittelt werden.

Der Punkt als Trenner ist SQL-Standard, man kann in der Verbindungsfolge SQLConnect mittels "naming=*sys" auf AS/400-Modus umschalten, dann gilt "/" als Trenner und unqualifizierte Tabellenzugriffe erfolgen über die Bibliotheksliste (nicht empfehlenswert).

PS:
Damit du nicht weiter suchst, das selbe gilt auch für Foreign Keys!

[caltmann]

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

[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.

[B.Hauser]

Wenn die Tabelle als normale PF per DDS definiert ist, gibt es keine PrimaryKeys!

Primary Keys können nur per SQL definiert werden:

alter table mytable
constraint MyTablePrimary PRIMARY KEY (Column1, ...)

Das würde ich so nicht unterschreiben!
Mit dem CL-Befehl ADDPFCST (PF-Integritätsbed. hinzufügen) können auch für DDS beschriebene physische Dateien Primary Keys, Unique Keys, Referentielle Integritäten und Check-Constraints angelegt werden.

ADDPFCST FILE(MYLIB/MYFILE)  
         TYPE(*PRIKEY)       
         KEY(KEY1 KEY2) 

ADDPFCST FILE(MYLIB/MYFILE)        
         TYPE(*REFCST)             
         KEY(KEY1 KEY2)            
         PRNFILE(PARFILE)          
         PRNKEY(PARKEY1 PARKEY2) 

... nur auf der AS/400 verwendet kaum jemand Primary und Foreign Keys oder Referentielle Integritäten.