Hilfe! BDE bleibt stehen

[Geert Dade]

Hallo Allerseits !

Ich hatte das folgende Problem unter "Datenbank " gepostet, aber eigentlich gehört es eher hier her:

Folgendes Problem können wir nicht lösen:

ALS TEST IN EINEM EXE SIMPLIFIZIERT:
- Eine lokale Paradox Datenbank
- Anbindung über TDatabase-Komponente (einmalig zur Laufzeit erstellt)
- Eine TQuery (einmalig zur Laufzeit erstellt)

Eine Abfrage über drei Tabellen (mit JOIN) ergibt ca. 50 Datensätze. Diese Query wird nach einer Pause von 1 ms geschlossen, das SQL-Statement neu geschrieben und der Query wieder geöffnet.

Bei einigen Systemen kommt nach einigen zigtausend Aufrufen zunächst die Meldung "Speicher nicht ausreichend" (o.ä.) für JEDEN Aufruf, bevor sich die BDE nach einigen weiteren zigtausend Aufrufen endgültig systemweit verabschiedet (heißt: kein BDE-Programm - incl. BDEAdmin - mehr startbar). Fehlermeldung aus IDAPI-DLL, Adresse 8E000000. Beendet man alle BDE-Anwendungen, läßt sich Alles ohnen Neustart des Rechners zunächst wieder betreiben.
Auf einem anderem Rechner (Win2K, 800 MHz) läuft der gleiche Test störungsfrei (bisher ca. 2.000.000 Aufrufe).

Der Hinweis "DIE BDE IST MIST - NEHMT ... (z.B. ADO)" hilft hier nicht weiter, da es sich um eine Applikation handelt, die seit Jahren so oder in ähnlicher Form bei diversen Kunden erfolgreich im Einsatz ist und nicht von jetzt auf gleich abgelöst werden kann.

Hier die Systemdaten des "Problemfalls":

CPU P4, 3,2 GHz, 512 MB HSp.
WIN XP Prof SP 2
BDE Version (DLL's 5.11, Admin 5.01)
Delphi5 und 7 ergeben das gleiche Resultat
BDEADMIN-SYSTEM-INIT-Einstellungen: (Haben wir für den Test hochgesetzt)
- AUTO ODBC: FALSE
- DEFAULT DRIIVER: PARADOX
- LANGDRIVER: PDOX ANSI INTL
- LOCAL SHARE: TRUE (mit FALSE (Standard) haben wir es auch probiert)
- LOW MEM USAGE: 32
- MAXBUFSIZE: 16384
- MAXFILEHANDLES: 396
- MINSIZE: 32
- MTS-POOLING: FALSE
- SHAREDMEMLOCATION: <leer> (Setzen von "5BDE" führte zu Fehlern in MIDAS)
- SHAREDMEMSIZE: 8192
- SQLQUERYMODE: <leer>
- SYSFLAGS: 0
- VERSION: 4.0

Hintergrund ist ein System mit zwei NT-Diensten und mehreren verteilten Win32-Exes, die 'normal' oder über multithreading auf mehrere Datenbanken (PARADOX, SQL SERVER, ORACLE) zugreifen - UND DAS HAT SEIT JAHREN FUNKTIONIERT !

Es wäre prima, wenn jemand einen genial einfachen Tip für eine entsprechenden BDE-Parameter oder eine winzige Codeanpassung hätte.

Gruß,
Geert

[AndreasLinke]

versuche doch mal , vor jeder Query ein flushbuffer zu setzen,
das könnte die Lösung sein.

MfG Andrea

[Geert Dade]

Hi Andreas,

danke für den Tipp. Ich verwende diesen Befehl bisher nur für Aktualisierungen der Datenmenge, nicht für eine SELECT-Projektion. (steht eigentlich auch im Widerspruch zur Delphi-Hilfe).

Aber - Versuch macht kluch - ich probiere es aus und werde hier morgen (Test benötigt an die 12 Stunden, um die BDE zu schrotten) berichten.

Gruß,
Geer

[Geert Dade]

Hi Andreas,

danke für den Tipp. Ich verwende diesen Befehl bisher nur für Aktualisierungen der Datenmenge, nicht für eine SELECT-Projektion. (steht eigentlich auch im Widerspruch zur Delphi-Hilfe).

Versucht habe ich es trotzdem. Resultat: nach ziemlich genau 10.000 Durchläufen kommt die Reaktion: "Operation nicht anwendbar" - und das war's dann.

Gruß,
Geer

[Heiko Luettge]

Probier mal folgendendes :

Mache vor jedem Aufruf ein Prepare und danach Unprepare.

Heik

[Geert Dade]

Hi Heiko,

... läuft jetzt im Test - aber das Ende ist (jetzt nach 15.000 Durchläufen) bereits absehbar:
CPU-Auslastung und Speicherbedarf steigen an, Geschwindigkeit hat sich um den Faktor 10 verlangsamt. Aber der Test hatte schon einen positiven Nebeneffekt: Die Meldung "Sperrungs-Datei zu groß" veranlasste mich, "LOCAL SHARE" wieder auf "False" zu setzen.
Die problematischen Tests sprechen eine PARADOX-Datenbank an. Im Widerspruch zu unseren ersten Tests scheint eine SQL Server Datenbank (über BDE - ODBC angesprochen) diese Probleme nicht zu haben.

Gruß,
Geer

[Geert Dade]

Nach immer weiterer Entschlackung:

Der Fehler tritt erst dann nicht mehr auf, wenn ich die SQL-Anweisung von JOIN befreie.

Das Problem liegt also offensichtlich, wie von Allen, die als Abhilfe "FlushBuffers" und "UnPrepare" vorschlugen, bereits vermutet, in nicht freigegeben resources für temporäre Zwischentabellen.
Schießen der Datenbank und der Session hilft leider auch nicht weiter - beim Schließen und wieder erneuten Öffnen einer Session gehen die Anzahl der Handles und der verwendete Speicher steil nach oben, eine getrennte session anlegen und wieder freigeben hat den gleichen Effekt.

Ich werde mich dann wohl einige Zeit aus der sonstigen Entwicklung ausklinken und die Datenbankschnittstelle umstellen ..