ODBC DB2/DB400 SQLSetPos

[caltmann]

Hallo!

Beim Versuch mittels ODBC-Calls auf die iSeries zuzugreifen
(Cursor mit FetchNext, usw.) ist das Problem aufgetreten,
dass Sätze mit SQLSetPos (und "SQL_DELETE") nicht
gelöscht werden konnten.
Die selbe Befehlsabfolge funktioniert bei einer lokalen DB2
aber ohne Probleme. Die ODBC-Einstellungen wurden schon überprüft. Mittels "DELETE FROM..."-Statement klappt es auch ohne Probleme. Nur bei der SQLSetPos-Variante kommt
"[iSeries Access ODBC-Treiber]Treiber ist nicht funktionsfähig. (30058)". Der mit dieser Fehlernummer verbundene englische Text "Driver not capable" ist wohl etwas sprechender.
Bedeutet dass jetzt aber, dass dies der Treiber von Haus aus
gar nicht unterstützt, oder würde er gerne und kann nicht (aufgrund von fehlenden Parametern o.Ä.)?
Die "normalen" Attribute wurden bereits entsprechend gesetzt,
sonst würde der "DELETE FROM"-Befehl ja auch nicht gehen, oder?

Danke f.Infos/Links, das 880-Seiten-PDF
"iSeries Access for Windows - Programming" habe ich,
aber eben noch nicht ganz durchgelesen ;-)

Ciao
Chris

[Fuerchau]

Das Problem ist hier ggf. der Cursortyp.
Wenn du nur einen Lesecursor hast, funktioniert das so auch nicht.
"DELETE FROM" als eigener Befehl ist auch nicht vom Cursor abhängig und funktioniert deshalb.

[caltmann]

Den Cursor hatte ich aber eigentlich mittels "SQLSetStmtAttr"
und "SQL_ATTR_CONCURRENCY" zum Test bereits auf
"SQL_CONCUR_VALUES" gesetzt, der ODBC-Treiber dreht den dann zwar auf "SQL_CONCUR_LOCK" um (= Cursor uses the lowest level of locking sufficient to ensure that the row can be updated). Ich schließe aber daraus, dass er dann
trotzdem "update"-fähig ist. Auch "SQL_ATTR_ACCESS_MODE"
ist auf "SQL_MODE_READ_WRITE".
Da es ja mit der DB2 funktioniert, vermute ich irgendeinen
weiteren Attributwert, der bei "iSeries Access ODBC" auf 0 und beim "DB2 ODBC Driver" standardmäßig auf 1 ist, oder umgekehrt.
Ich werde versuchen, einmal alle Attribute (auch scheinbar uninteressante) auszulesen und gegenüberzustellen.
Mal sehen. Ich wollte nur vorfühlen, ob das vielleicht ein
weitläufig bekanntes Problem ist.
Danke + Ciao
Chris

[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

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