View Full Version : ODBC DB2/DB400 SQLSetPos
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
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.
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
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.
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
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
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!
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
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.
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