ODBC-Probleme und Umgehungen

[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

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)

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.