SQL-Befehl "DELETE" macht Probleme

[Neptun]

Hallo!

Ich habe eine OleDbConnection mit IBMDA400 aufgebaut. Änderungsbefehle wie INSERT oder UPDATE laufen in einer OleDBTransaction ab. So weit so gut, nun kommt aber der Befehl "DELETE". Dieser läuft natürlich ebenfalls in einer OleDbTransaction ab.

Hier der Befehl:
DELETE FROM TESTLIB.TESTTAB WHERE FELD1 = 'A' AND FELD2 = 'B'

(Funktioniert über ODBC einwandfrei)

Unter OleDB kommt folgende Fehlermeldung:
Message "CPF9812: Datei DELETE in Bibliothek *LIBL nicht gefunden."


Hä? Wieso interpretiert die AS400 den Befehl "DELETE" als Datei? Oder ist die Fehlermeldung irreführend? Mache ich etwas falsch?

Auf anderen Datenbanken (SQL Server, Oracle) läuft der o.g. DELETE problemlos ab!? (Dort fehlt natürlich die Angabe der Bibliothek vor dem Tabellennamen)

Gruß
Neptun

[ThiloSiemon]

Ist evtl. die Syntax nicht ok?
iSeries erwartet als Ternnung LIB/Tabelle ein Slash. Wie wird der Punkt übersetzt?
DELETE FROM TESTLIB/TESTTAB WHERE FELD1 = 'A' AND FELD2 = 'B'

[Neptun]

Habe es gerade nochmal probiert mit "/" und auch ganz ohne Bibliothek-Präfix. Es kommt immer CPF9812.

Weiß jemand Rat?

Gruß
Neptun

[kuempi von stein]

Habe es gerade nochmal probiert mit "/" und auch ganz ohne Bibliothek-Präfix. Es kommt immer CPF9812.

Weiß jemand Rat?

Gruß
Neptun

mhh..
lege doch mal spasseshalber eine datei namens DELETE an mit den feldern und schieb da mal nen satz rein und lass das statement dann laufen.....
löscht der dann den satz von da?

k.

[ThiloSiemon]

Formatierten Nachrichtentext anzeigen
System:
Nachrichten-ID . . . . . . . : CPF9812
Nachrichtendatei . . . . . . : QCPFMSG
Bibliothek . . . . . . . . : QSYS

Nachricht . . . : Datei &1 in Bibliothek &2 nicht gefunden.
Ursache . . . . : Der Dateiname oder der Bibliotheksname ist nicht richtig.
Wurde der Bibliotheksname nicht angegeben, befindet sich die Datei
möglicherweise in einer Bibliothek, die nicht in der Bibliotheksliste
vorhanden ist.
Fehlerbeseitigung: Den Datei- bzw. Bibliotheksnamen berichtigen oder den
Bibliotheksnamen der Bibliotheksliste hinzufügen. Die Anforderung
anschließend wiederholen.

Auf iSeries den JOB betrachten und schauen, was genau er absetzt. Wenn die SQL - Syntax falsch ist, kommen manchmal Meldungen, die irreführend sind, weil sie einen auf die falsche Fährte führen.

[Neptun]

mhh..
lege doch mal spasseshalber eine datei namens DELETE an mit den feldern und schieb da mal nen satz rein und lass das statement dann laufen.....
löscht der dann den satz von da?

k.

muarharharharhar ... ich lach mich wech
Nachdem ich die Datei "DELETE" mit den gleichen Feldern in einer Bibliothek angelegt habe welche in der Liste des Jobs stand, wurde kein Fehler mehr zurückgegeben!!!!! Allerdings war der Satz auch nach dem Festschreiben der Transaktion in dieser Datei noch vorhanden (auch die eigentliche Datei war unverändert).

Übrigens:
Wenn ich das Ganze über den CA-ODBC Treiber laufen lasse, funzt das alles einwandfrei. Nur der CA-OleDb Provider "IBMDA400" will nicht so recht ...


Gruß
Neptun

[Neptun]

Ist der IBMDA400 Provider denn tatsächlich so mit Bugs versehen?

Gruß
Neptun

[Fuerchau]

Wenn du das Statement ausführst musst du ggf. den Typ des Statements angeben !
OLEDB (das hat mit dem Treiber nix zu tun) versucht erst mal einen "SELECT * FROM xxx" !

Also:
MyConnect.Execute "delete ...",,adCmdText
Oder
MyCmd.CommandText="Delete ..."
MyCmd.CommandType=adCmdText
MyCmd.execute

Der Default für CommandType im Execute ist "adCmdTable" !

[Neptun]

Hi!

CommandType steht auf Text. Das sollte es also nicht sein.

Ich arbeite mit dem OleDbCommandBuilder. Hier die Syntax des Aktualisierungscodes:

((OleDbDataAdapter) m_Adap).SelectCommand = new OleDbCommand(SelectCommand, (OleDbConnection) m_Conn);

((OleDbDataAdapter) m_Adap).SelectCommand.Transaction = (OleDbTransaction)m_Trans;

OleDbCommandBuilder OleDbBldr = new OleDbCommandBuilder((OleDbDataAdapter) m_Adap);

((OleDbDataAdapter) m_Adap).Update(DT);


DT ist vom Type DataTable. Dort stehen die geänderten Daten drin. Im SelectCommand.Text ist ein Select auf die zu ändernde Tabelle drin. Getestet mit Oracle, MSDE, MS SQL Server, MySql, Sybase. Funktioniert überall problemlos.

Jetzt habe ich auf Google gefunden, dass der CommandBuilder nicht alle Plattformen unterstützt. Hat schon einmal jemand den OleDbCommandBuilder oder OdbcCommandBuilder mit dem IBMDA400 Provider benutzt?


Gruß
Neptun

[Fuerchau]

Das Problem ist eher der IBMDA400, der leider nicht alles unterstützt !
Laut Doku wird z.B. bei SQL keine Transaktion (Commit/Rollback) unterstützt. Verwende besser den MSDASQL mit dem ODBC-Treiber von CA. Damit dürftest du keine Probleme haben.
Insbesonders sorge dafür, dass du auf deinen AS/400-Tabellen einen UNIQUE-Index/LF hast, damit Datensätze per Bookmark eindeutig erkannt werden.

Mit dem IBMDA400 habe ich ausschließlich schlechte Erfahrungen gemacht.

[Neptun]

Das Problem ist eher der IBMDA400, der leider nicht alles unterstützt !
Laut Doku wird z.B. bei SQL keine Transaktion (Commit/Rollback) unterstützt. Verwende besser den MSDASQL mit dem ODBC-Treiber von CA. Damit dürftest du keine Probleme haben.
Insbesonders sorge dafür, dass du auf deinen AS/400-Tabellen einen UNIQUE-Index/LF hast, damit Datensätze per Bookmark eindeutig erkannt werden.

Mit dem IBMDA400 habe ich ausschließlich schlechte Erfahrungen gemacht.

Hmm, MSDASQL. Das ist meines Wissens nach doch ein OleDB Provider welcher dann den ODBC-Treiber aufruft und darüber den Zugriff macht. Also da sollte die direkte Nutzung des ODBC-Treibers doch schneller sein, oder? Der OleDb-Provider MSDASQL scheint mir da nur ein zusätzlicher und unnötiger Overhead zu sein. Wenn man natürlich (aus welchem Grund auch immer) OleDb nutzen muss, dann wäre das natürlich eine mögliche Lösung.

Beim V5R3 gibt es doch neue OleDb Provider von IBM. Sind die besser als der IBMDA400? Und hat schon einmal jemand mit dem OleDB Provider vom HIS 2004 (Microsoft Host Integration Server) gearbeitet?


Gruß
Neptun