ODBC-Probleme und Umgehungen

[Fuerchau]

Hallo Leute,

nur so zur Info bezgl. des manchmal seltsamen Verhaltens bei ODBC-Zugriffen.

Da ich mit FTSolutions ein BI-Software entwickle und vertreibe muss ich mich ja intensiv mit dem ODBC beschäftigen (ja ja ich weiß, mit Java wäre ja alles kein Problem, aber wer weiß ...).

Aus bekannten Gründen soll man ja bei SQL's mit Parametermarkern "?" arbeiten.
Dies habe ich auch intensiv genutzt. Bei verschiedenen Kundensystemen liefen diese SQL's aber sporadisch auf Fehler!

"PWS0043 - Parameterwert nicht verwendbar"
"Anzahl Parameter falsch"
Oder sogar keine Daten obwohl Daten da sind!

Das macht einen schon wahnsinnig wenn die SQL's mal laufen und mal nicht. Eine Regel gibts da überhaupt nicht.
Ein SQL-Trace (ODBC-Manager) oder Jobolog (Debug-Modus) brachte überhaupt keinen Hinweis, was denn da so falsch läuft.
Im Joblog stand nur lapidar:
... Cursor geöffnet (also war der SQL ja OK)
... Cursor geschlossen (ohne Datenabruf)

Nun bin ich zu meinem Lieblingsthema gekommen und habe mal CCSID's geprüft. Und sieh da, der Systemwert QCCSID bei den betroffenen Systemen steht auf 65535, *HEX.
Normalerweise ist das wohl kein Problem, da der QZDASOINIT-Job trotzdem auf eine korrekte CCSID gestellt wurde.

Aber was mach der ODBC-Treiber oder der Serverjob (wer ist letztlich egal).
Für Optimierungen und Wiedererkennung von SQL's werden nämlich sämtliche Konstanten selbstständig in Parametermarker überführt und dann ins SQLPKG gestellt, bzw. gesucht, ggf. gefunden usw.

Enthält nun ein SQL sowohl Konstanten als auch gleichzeitig Parametermarker scheint diese Mimik ab und zu nämlich daneben zu gehen.
Hier half ein wenig Googeln (ich weiß nicht mehr wo das war), da wird nämlich bezogen auf eine andere CCSID geschrieben, dass bei dieser Art der Übersetzung Probleme auftauchen können, wenn die ClientCCSID (hier die Codepage) zur AS/400 (hier *HEX) abweicht.

Dazu gab es nur eine Lösung:
Entweder alle Konstanten als Parameter ersetzen oder eben ungedreht.
Da ich eine zentrale Routine für Execute-Aufrufe hatte, war letzteres die schnellste Lösung.
Kurzerhand ein neues CMD-Objekt aus dem alten erstellt und sukzessive (unter Berücksichtigung des Feldtyps) jedes "?" durch seinen Inhalt ersetzt.

Und siehe da:
Alle SQL's laufen problemlos auch auf diesen problematischen Systemen!!!

Zu guter letzt hatte ich allerdings noch ein weiteres Problem:
Spradisch blieb mein Progrämmchen einfach stehen und wollte nichts mehr tun.
Der QZDA-Job stand auf "recv", im Joblog gabs keine Hinweise und ich konnte nur noch den Taskmanager zum Killen verwenden.

Da ich mitunter sehr viele Einzel-Selects auf die AS/400 loslasse habe ich nun festgestellt, dass nach ca. 7.350 Queries der ODBC-Treiber oder der QZDA-Job nicht mehr wollen!!!

Ich hatte also nun die Anzahl Queries gezählt und nach 5000 dann die Verbindung geschlossen und wieder aufgemacht. Allerdings schlagen hier 2 Funktionen zu:
a) Connection-Pool
b) Wiederverwendung eines QZDA-Jobs
So war dann halt nach 2530 weiteren Queries wieder Schluss.

Also habe ich meine offene Verbbindung in ein Collection-Objekt geschoben und eine neue verbindung aufgemacht.
Und so habe ich nun auch diese unverständliche Grenze umgangen.

Falls der wiederverwendete Job noch ein Problem darstellen wird, kann ich noch einen ENDJOB per QCMDEXC hinterherjagen.
So gebe ich nun alle Verbindungen erst bei Programmende frei.

Das wars mal so aus dem Nähkästchen.
Vielleicht hat ja der eine oder andere auch so unerklärliche Probleme und kann hieruas vielleicht eine Lösung ziehen.

[andreaspr@aon.at]

Zu guter letzt hatte ich allerdings noch ein weiteres Problem:
Spradisch blieb mein Progrämmchen einfach stehen und wollte nichts mehr tun.
Der QZDA-Job stand auf "recv", im Joblog gabs keine Hinweise und ich konnte nur noch den Taskmanager zum Killen verwenden.

Da ich mitunter sehr viele Einzel-Selects auf die AS/400 loslasse habe ich nun festgestellt, dass nach ca. 7.350 Queries der ODBC-Treiber oder der QZDA-Job nicht mehr wollen!!!

hi baldur,

dieses problem hatte ich auch mit dem ODBC. selbst die .net-profis konnten mir da nicht wirklich weiter helfen.
die verbindung habe ich auch jedes mal nach einer sql-anweisung geschlossen. da aber die verbindung durchs pooling dennoch offen blieb halft mir das nicht viel weiter.
Habe auch die sql-abfragen in seperate threads gestartet, damit die gui nicht gesperrt wird.

mit den parametern ("?") hatte ich auch probleme, speziell mit dem datentyp timestamp der db2. anzeige ging, aber updates bzw. wenn ich dieses feld in der where-klausel als bedingung hinterlegte gabts probleme. (der odbc-treiber hatte die letzten tausendstel sek. abgeschnitten)

kurz gesagt, hab ich mich dazu entschlossen den db2.net provider der ibm zu verwenden. mit dem hab ich gar keine probleme mehr.
ist zwar nicht plattform unabhängig, ist meine anwendung aber eh nicht, da ich auch mit den systemtabellen der db2 arbeite, die ja von system zu system unterschiedlich sind (falls überhaupt vorhanden).

[Fuerchau]

Bzgl. des Timestamps liegt es an den ODBC-Richtlinen, die das Format vorgeben.
Hier hilft nur der Typ String und die korrekte Aufbereitung im AS/400-Format, da funktionieren dann auch Microsekunden.

Was die Systemtabellen (SYSxxx) angeht, so existieren sie auf jedem System.
Allerdings gibt es da ein paar Einschränkungen.
Arbeitet man mit einer SQL-Collection (CREATE SCHEMA/COLLECTION) werden in dieser Lib Views für die Systemtabellen erstellt, so dass Schemaabfragen nur diese Sichten berücksichtigen (wenn diese Lib Default-Lib ist).

Der DB2.NetProvider hat mir in der aktuellen Version (V5R4) nicht gefallen, da er keine Schemaabfragen wie es sich gehört unterstützt und ich keine Lust hatte, diese nachzuprogrammieren.
Ausserdem ist er auch noch NET 1.1 basiert, unterstützt also nur die IDB-Schnittstellen und erbt nicht von den DB-Klassen.
Dadurch gibt es keine vernünftige Designerunterstützung mit Klassengenerierungen und Linq ist daher auch nicht so einfach.
Da ist auch der ODBC/OLEDB-Provider besser und die Performanceeinbußen sind äußerst gering wenn überhaupt messbar.

[BenderD]

Hallo Baldur,




(ja ja ich weiß, mit Java wäre ja alles kein Problem, aber wer weiß ...).

Allerdings schlagen hier 2 Funktionen zu:

a) Connection-Pool
b) Wiederverwendung eines QZDA-Jobs
So war dann halt nach 2530 weiteren Queries wieder Schluss.



Mit Java hast du im wesentlichen dasselbe Problem, das ist nämlich ein Server/Treiber Problem und kein Client Problem. Dort würde das genau Aufgabe eines vernünftigen Connection Pools sein, dass der sich um die Gesundheit der Connections kümmert - und den kann mann dann parametrisieren (keep alive check, use count, timeouts etc...). Bei ODBC geht das auch, die Frage ist nur, ob es da einen entsprechenden Leistungsfähigen Connection Pool gibt. Micro Strategy hat sowas offenkundig, die gehen auch über ODBC und das funzt.

D*B

[Fuerchau]

MS-ADO unterstützt automatisch über seinen OLEDB-Treiber (MSDASQL) für ODBC-Verbindungen einen Connection-Pool, den man auch explizit abschalten kann.
Das Problem ist wohl leider nicht nur auf die Verbindung beschränkt sondern ggf. auch auf den QZDA-Job.
Da diese Jobs automatisch wiederverwendet werden (Siehe PJ-Einstellungen im Subsystem) könnte die Anzahl der Queries hier noch ein Problem sein.
Ich denke aber eher, dass es ein Problem des Treibers selber ist.
Es macht nämlich keinen Unterschied ob das Recordset explizit geclosed oder automatisch zerstört wird (implizit close).
Auch diverse Einstellungen (Mit/Ohne LazyClose, Mit/Ohne SQLPKG) brachten keine Veränderung.

[Fuerchau]

Was die Begrenzung der 7350 Queries angeht konnte ich dieses nun mit einem kleinen VBA-Programm leider nicht nachvollziehen.
Nach 20.000 Queries (allerdings immer der selbe) habe ich dann mal abgebrochen.

Es muss irgendwie damit zusammenhängen, dass ich eine Multithread-Anwendung habe, die mit mindestens 2 Tasks, jede mit einer eigenen Verbindung) parallele Abfragen losschickt. Laut QZDA-Job und Joblog werden jedoch ODP's immer schön wiederverwendet und keine zusätzlichen Dateien aufgemacht.

Eine nähere Analyse wird da alleine aus Zeitgründen nichts bringen, ich habe ja eine Umgehung.

[Fuerchau]

Für alle die es interessiert:

Die Umgehungslösung funktionierte nun längerfristig doch nicht. Sie hat das Hauptproblem nur verzögert.
M.a.W, der Programmhänger trat erheblich später trotzdem auf.

Nach ein wenig googeln bin ich dann auch endlich auf die Ursache gekommen:
An ADO-based application may stop responding when it uses the adAsyncExecute option to open a Recordset object in Windows Server 2003 or in Windows XP (http://support.microsoft.com/kb/955843/en-us)

Genau dieses ist das was ich mache.
Mit tausenden von Queries, die ich asynchron machte, hat ADO eben ein Ressourcenproblem und landet letztendlich im Deadlock.

Die Installation des Hotfixes brachte leider keine Verbesserung sondern sogar zusätzliche Probleme:
Näheres siehe hier:
Breaking change in MDAC ADODB COM components in Windows 7 Service Pack 1 (repost with MSDN liveID) (http://social.msdn.microsoft.com/Forums/en/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13)

D.h., das Hotfix installiert die 32-Bit-Komponenten des Windows-7 SP1!

Ich könnte also meine Anwendung nur auf Systemen installieren, die ebenso dieses Hotfix installiert haben.

Schöne Sche...!

Ich habe nun das Hotfix wieder deinstalliert und alle Asynchron-Aufrufe in Synchron-Aufrufe geändert, ist zwar unschön, da die Anwendung z.T. eben nicht mehr reagiert (im Fenstertitel mit Hinweis), was einen User zum Abbruch der Anwendung verleiten könnte.
Aber das kann man ja erklären, ausserdem ist es normalerweise eine Batchanwendung.