ODBC und Journaling

[Neptun]

Hallo!

Mir ist immer noch nicht klar, wer hier wo das Journaling einschaltet. Wenn ich die Journale auf der AS/400 abhänge, kann ich keine Daten hineinschreiben.

Im CA ODBC-Treiber ist COMMIT *NONE eingestellt.

Hier das ODBC-Log vom Connect (bevor der erste Tabellen-Zugriff erfolgt):
cblconfi dbload a74-a78 ENTER SQLAllocEnv
HENV * 6060EC14
cblconfi dbload a74-a78 EXIT SQLAllocEnv with return code 0 (SQL_SUCCESS)
HENV * 0x6060EC14 ( 0x01281540)
cblconfi dbload a74-a78 ENTER SQLAllocConnect
HENV 01281540
HDBC * 001283F8
cblconfi dbload a74-a78 EXIT SQLAllocConnect with return code 0 (SQL_SUCCESS)
HENV 01281540
HDBC * 0x001283F8 ( 0x012815e8)
cblconfi dbload a74-a78 ENTER SQLConnectW
HDBC 012815E8
WCHAR * 0x012816F0 [ -3] "catst\ 0"
SWORD -3
WCHAR * 0x1F7A9D2C [ -3] "******\ 0"
SWORD -3
WCHAR * 0x1F7A9D2C [ -3] "******\ 0"
SWORD -3
cblconfi dbload a74-a78 EXIT SQLConnectW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
WCHAR * 0x012816F0 [ -3] "catst\ 0"
SWORD -3
WCHAR * 0x1F7A9D2C [ -3] "******\ 0"
SWORD -3
WCHAR * 0x1F7A9D2C [ -3] "******\ 0"
SWORD -3
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 6 <SQL_DRIVER_NAME>
PTR 0x01281DD0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 6 <SQL_DRIVER_NAME>
PTR 0x01281DD0 [ 22] "CWBODBC.DLL"
SWORD 510
SWORD * 0x00128278 (22)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 7 <SQL_DRIVER_VER>
PTR 0x01281FE0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 7 <SQL_DRIVER_VER>
PTR 0x01281FE0 [ 16] "04.05.00"
SWORD 510
SWORD * 0x00128278 (16)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 10 <SQL_ODBC_VER>
PTR 0x01281DD0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 10 <SQL_ODBC_VER>
PTR 0x01281DD0 [ 20] "03.52.0000"
SWORD 510
SWORD * 0x00128278 (20)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 17 <SQL_DBMS_NAME>
PTR 0x01281DD0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 17 <SQL_DBMS_NAME>
PTR 0x01281DD0 [ 22] "DB2/400 SQL"
SWORD 510
SWORD * 0x00128278 (22)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 18 <SQL_DBMS_VER>
PTR 0x01281FE0
SWORD 510
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 18 <SQL_DBMS_VER>
PTR 0x01281FE0 [ 20] "04.03.0002"
SWORD 510
SWORD * 0x00128278 (20)
cblconfi dbload a74-a78 ENTER SQLGetFunctions
HDBC 012815E8
UWORD 40
UWORD * 0x00128274
cblconfi dbload a74-a78 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 40
UWORD * 0x00128274 (1)
cblconfi dbload a74-a78 ENTER SQLGetFunctions
HDBC 012815E8
UWORD 54
UWORD * 0x00128274
cblconfi dbload a74-a78 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 54
UWORD * 0x00128274 (1)
cblconfi dbload a74-a78 ENTER SQLGetFunctions
HDBC 012815E8
UWORD 50
UWORD * 0x00128274
cblconfi dbload a74-a78 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 50
UWORD * 0x00128274 (1)
cblconfi dbload a74-a78 ENTER SQLSetConnectOption
HDBC 012815E8
SQLINTEGER 102 <SQL_AUTOCOMMIT>
SQLPOINTER 0x00000000
cblconfi dbload a74-a78 EXIT SQLSetConnectOption with return code 0 (SQL_SUCCESS)
HDBC 012815E8
SQLINTEGER 102 <SQL_AUTOCOMMIT>
SQLPOINTER 0x00000000
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 72 <SQL_TXN_ISOLATION_OPTION>
PTR 0012827C
SWORD 4
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 72 <SQL_TXN_ISOLATION_OPTION>
PTR 0012827C
SWORD 4
SWORD * 0x00128278 (4)
cblconfi dbload a74-a78 ENTER SQLSetConnectOption
HDBC 012815E8
SQLINTEGER 108 <SQL_TXN_ISOLATION>
SQLPOINTER 0x00000001
cblconfi dbload a74-a78 EXIT SQLSetConnectOption with return code 0 (SQL_SUCCESS)
HDBC 012815E8
SQLINTEGER 108 <SQL_TXN_ISOLATION>
SQLPOINTER 0x00000001 (BADMEM)
cblconfi dbload a74-a78 ENTER SQLGetInfoW
HDBC 012815E8
UWORD 15 <SQL_ODBC_SQL_CONFORMANCE>
PTR 0x0012827A
SWORD 2
SWORD * 0x00128278
cblconfi dbload a74-a78 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS)
HDBC 012815E8
UWORD 15 <SQL_ODBC_SQL_CONFORMANCE>
PTR 0x0012827A (1)
SWORD 2
SWORD * 0x00128278 (2)



Wenn es der SQL_AUTOCOMMIT nicht sein soll, dann kann es doch nur noch die SQL_TXN_ISOLATION_OPTION sein, oder?

Die Doku meines Tools schweigt sich zu den COMMIT-Einstellungen leider aus ...

Kann man das nicht irgendwie auf der AS/400 grundsätzlich abhängen für eine Bibliothek oder so, dieses nicht gewollte ODBC-Journaling?


Gruß
Neptun

[Fuerchau]

Nein kann man nicht.
Einzig und allein die Anwendung entscheidet über das Journal.
Sonst könnte ich ja bei jeder Anwendung das Journal einfach abstellen und die Fehler wären bereits produziert (Commit wäre ja nicht so schlimm, aber ROLLBACK würd nicht mehr gehen und das wäre ganz schlimm).

Solange du deinem COBOL-Programm nicht beibringen kannst, ohne Commit zu arbeiten, kannst du das Journal nicht abstellen.

Wende dich an den Hersteller des COBOL-Compilers bzw. SQL-Precompilers.

[Neptun]

Nein kann man nicht.
Einzig und allein die Anwendung entscheidet über das Journal.
Sonst könnte ich ja bei jeder Anwendung das Journal einfach abstellen und die Fehler wären bereits produziert (Commit wäre ja nicht so schlimm, aber ROLLBACK würd nicht mehr gehen und das wäre ganz schlimm).

Solange du deinem COBOL-Programm nicht beibringen kannst, ohne Commit zu arbeiten, kannst du das Journal nicht abstellen.

Wende dich an den Hersteller des COBOL-Compilers bzw. SQL-Precompilers.

Ok, die Quelle des Übels ist somit ganz klar eingekreist. Danke!
Mal sehen was der Tool-Hersteller sagt

Gruß
Neptun

[Neptun]

Hallo!

Der SQL-Befehl lautet
'SET TRANSACTION ISOLATION LEVEL NO COMMIT'

So weit so gut. Wenn ich im ODBCTE32.EXE einen anderen Level angebe, kann ich grundsätzlich nicht in die AS/400-Tabellen schreiben (wenn die Datei nicht im Journal aufgezeichnet wird).

Von einer IBM-Seite:

SET TRANSACTION---------------------------------------------->

(1)
>----ISOLATION LEVEL--+-NO COMMIT--------------------------+---><
| (2) |
+-READ UNCOMMITTED , READ WRITE------+
| (3) |
+-READ COMMITTED---------------------+
| (4) |
+-REPEATABLE READ--------------------+
| (5) |
'-SERIALIZABLE-----------------------'


Wenn man nun SQL_TXN_ISOLATION per ODBC-Treiber setzen möchte, fehlt aber die hier von IBM aufgeführte erste Option "NO COMMIT" !!!
Wie kann ich diese Option über ODBC setzen? Oder anders gefragt: Welcher ODBC-Befehl entspricht 'SET TRANSACTION ISOLATION LEVEL NO COMMIT' ?


Gruß
Neptun

[Fuerchau]

Deine SQL-Runtime unterstützt das anscheinend nicht !
Da du embedded SQL verwendest, fängt deine SQL-Schicht den INSERT wohl ab, bevor er zum ODBC-Treiber kommt. Ggf. wird ein AUTO-COMMIT durchgeführt, der ja auch nicht geht.
Schalte den Auto-Commit mittels SQL-Option/Compiler (nicht im ODBC) zusätzlich ab.

Verwende ich native ODBC (über ADO/DAO/RDO/CLI) kann ich mittels aktueller ODBC-Commitstufe *NONE alles schreiben/löschen was ich darf.

Ich kann dir da leider nur raten auf eine andere Schnittstelle umzustellen (CLI oder VB/C++ und ADO) oder mit Journaling zu arbeiten.

[B.Hauser]

Hallo,

was ist, wenn Du Deinen SQL-Statement WITH NC (NC = No Commit) hinzufügst?

Also etwa so:

Insert into MySchema.MyTable
   values(.....)
   With NC 

Vielleicht hilfts ja!

Birgitta

[Neptun]

Hallo,

was ist, wenn Du Deinen SQL-Statement WITH NC (NC = No Commit) hinzufügst?

Also etwa so:

Insert into MySchema.MyTable
values(.....)
With NC 

Vielleicht hilfts ja!

Birgitta

@B. Hauser
Leider wird die SQL-Syntax für Befehle wie den INSERT komplett vom Tool generiert ... Jetzt bitte nicht schreien "Das ist aber sicher nicht optimal" oder so ... das wissen wir
Aber so ist momentan leider Stand der Dinge. Ich kann zusätzlich SQL-Befehle an die AS/400 schicken, welche kein Ergebnis liefern, also z.B. kann ich keinen SELECT machen (ist eine undokumentierte Funktion, durch Zufall herausgefunden). Theoretisch könnte ich auch den INSERT etc. darüber laufen lassen, aber dieser Ansatz (könnte man wohl als Embedded SQL bezeichnen) ist momentan erstmal nicht gewollt.

Trotzdem danke für den Tip, kann vielleicht mal nützlich sein


@Fuerchau
Tja, ich warte noch auf Antwort vom Hersteller. Ich wäre wirklich verwundert wenn die das nicht bedacht hätten...


Gruß
Neptun

[BenderD]

Hallo,

warum haben eigentlich im AS400 Umfeld so viele Leute was gegen Commit - das ist Stand der Technik und wer es nicht einsetzt, riskiert unnötig (juristisch: grob fahrlässig!) inkonsistente Daten.
Dass das Tool die SQL Statements generiert ist doch völlig in Ordnung, das verhindert eher Unfug.

@B. Hauser
Leider wird die SQL-Syntax für Befehle wie den INSERT komplett vom Tool generiert ... Jetzt bitte nicht schreien "Das ist aber sicher nicht optimal" oder so ... das wissen wir
Aber so ist momentan leider Stand der Dinge. Ich kann zusätzlich SQL-Befehle an die AS/400 schicken, welche kein Ergebnis liefern,
Neptun

Das senden von SQL Anweisungen ohne Rückgabe reicht doch völlig:
wen die Transaktion erfolgreich war, schickt man ein Commit hinterher, war es nix, dann eben ein Rollback.
Wenn man nun tatsächlich den Unfug bevorzugt Commit abzuschalten, dann sendet man halt einmal zu Beginn "SET TRANSACTION ISOLATION LEVEL *NONE" und ab dann kann die Anwendung auch kaputte Transaktionen permanet in die Datenbank schreiben: welchen Sinn das allerdings haben soll, entzieht sich meiner Kenntnis!!!

mfg

Dieter Bender

[Fuerchau]

Für neue Anwendungen ist das ja auch in Ordnung. Leider muss man manchmal Client-Programme auf existierenden ERP-Datenbanken entwickeln die häufig nicht journalisiert werden. Und dann steht man halt mit solchen "Tools" etwas im Regen.

[BenderD]

@Baldur: ich kann da keinen Regen erkennen. Es stellt überhaupt kein Problem dar eine Datenbank einer vorhandenen Anwendung zu journalisieren (wer hier an Platte spart, kann nicht wirklich rechnen). Ich bin zu meinen Zeiten als (Teil)Verantwortlicher noch einen Schritt weiter gegangen und habe grundsätzlich alles journalisiert, obwohl keine einzige Anwendung Commit verwendet hat - alleine die zusätzlichen Möglichkeiten bei Fehleranalyse lassen das sinnvoll erscheinen.

mfg

Dieter Bender

Für neue Anwendungen ist das ja auch in Ordnung. Leider muss man manchmal Client-Programme auf existierenden ERP-Datenbanken entwickeln die häufig nicht journalisiert werden. Und dann steht man halt mit solchen "Tools" etwas im Regen.

[Neptun]

Hallo!

Mir geht es beim Abschalten vom Journaling vor allem um die Performance. Ich denke mal, dass die Zugriffe um einiges zügiger ablaufen ohne Journaling, oder?
Ich spreche hier von Massenzugriffen, also sehr viele Befehle welche an die Datenbank übergeben werden.
Wieviel Prozent Performanceeinbuße hat man durch das Journaling, gibt es da Erfahrungswerte?

Gruß
Neptun