BDE hängt sich auf?

[Wolfgang Kaiser]

Borland BDE hängt sich bei kurzzeitigem Netzausfall auf?
Benötigen dringend Hilfe

4 PC's mit Windows98 arbeiten ständig mit den Daten auf einem NT-File-Server.
Die Anwendungen wurden mit Delphi3 entwickelt, genutzt werden die BDE mit Paradoxdateien.
Die Verbindung erfolgt über ein heterogenes Netz. Einer der Anwendungs-PC's hängt sich täglich nach folgenden Fehlermeldungen der BDE auf:
Error 11047, 10249 und manchmal 11109. ('unbekannter interner Fehler des Betriebssystems', ..'Timeout bei Sperrung' )

Nach einem solchen Fehler wird die BDE unerträglich langsam und erholt sich nicht mehr - auch wenn der Netzzugriff wieder ordentlich schnell möglich ist.
Nach einem solchen Fehler gelingt es nicht die Session zu schließen und wieder neu zu öffnen, auch ist es nicht möglich die Anwendung mit Application.Terminate zu beenden um danach neu zu starten.

Vermutlich liegt hier ein Problem des Netzes oder dessen Configurationen vor (Hinweise zur Configuration des NT-Servers, den TI's von Inprise (TI3342) und Microsoft Knowlegde Base Q129202; Q134637; Q124916 und Q126026 wurden schon erfolglos getestet) , da beim Kunden aber andere Anwendungen einwandfrei über das Netz laufen muß unsere Anwendung mit dem Problem in irgend einer Form auch fertig werden - s.o. zumindest Programm ordentlich beenden und neu starten können.

Mit freundlichen Grüßen Kaiser

[Andreas Kosch]

Hallo,

wenn die BDE "unerträglich langsam" wird und sich die Anwendung nicht mehr normal beenden lässt, gehe ich davon aus, dass zu diesem Zeitpunkt die BDE noch mit irgendwas beschäftit ist. Als erstes würde ich versuchen, den Zeitpunkt des "Aufhängens" mit einer konkreten Programmfunktion in Verbindung zu bringen. Es könnten die folgenden Ansatzpunkte in Frage kommen: <br>
a) Zugriff über einen zweiten Thread (2. Session) <br>
b) Datenabfrage über TQuery (SQL-Simulation der BDE) <br>
c) Explizite Transaktionssteuerung (Transaktions-Simulation der BDE) <br>
d) TSession-Eigenschaft PrivateDir und NetFileDir<br>

Die Fehlernummern 11<i>xxx</i> gehören zum Bereich <i>OS Error not handled by IDAPI</i>. Es stellt sich nun die Frage, ob das die primäre Ursache ist oder ob dies nur Seiteneffekte eines anderen Problems sind

[Wolfgang Kaiser]

Hallo Herr A. Kosch,

vielen Dank für Ihre Bemühungen mir zu helfen (auch zu den den vielen anderen hier im Forum gestellten Fragen - auch nicht unmittelbar Betroffene finden hier wie ich Ihre Hinweise sicher interessant zu merken).
Demnächst muß ich mich mit C/S D5 und Oracle beschäftigen und habe schon mal seit heute Ihr Buch "C/S ..." erworben (Anfragen hierzu werden sicher folgen), hier habe ich auch schon sonstige hier von Ihnen gegebene Hinweise zu Paradox und NT-Servern wiederentdeckt - werde ich genauer ansehen.

Aber mit meinem akt. Problem bin ich noch nicht weiter. Die Ansatzpunkte a-c treffen bei mir wohl nicht zu. PrivateDir liegt bei mir jeweils auf der lokalen HD im Verzeichnis der Programm-EXE; NetDir ist das dem Datenbankverzeichnis übergeordnete Verzeichnis auf dem Server.
Der Hinweis zur Kategorie der Fehlermeldungen war eine interessante neue Information, aber nach meiner bisherigen Fehlerprotokollierung kann ich nicht sagen, welcher der primäre Fehler sein sollte.

Die Applikation: Es werden von 4 PC's von je einem elektronischen System (Zutrittskontrolle) ständig die Zutrittsbuchungen abgeholt und auf dem Server gespeichert. Jeweils früh zum Schichtbeginn zur gleichen Zeit (in Differenz von ca. 10 Min.) hängt sich einer der 4 PC's wie geschildert auf (meine interne Fehlerprotokollierung - evtl. auch nicht abs. volständig: 10249, 11047 und manchmal 11109).
Das Netz beim Kunden ist sehr heterogen (20.000 - 30.000 PC's, was sonst noch evtl. zu dieser Zeit über die betreffenden Netzverbindungen /Router ,.. läuft ist mir unbekannt).

Zufällig nach Umzug in unserer Firma und gewisser Umgestaltungen unserer Netzverbindungen habe ich bei uns ein analoges Problem mit dieser Anwendungbei uns. Die Firma hat ein Novell-Netz für den allg. Betrieb und über die gleiche Verkabelung und einen Hub die Verbindung zum NT-Server der Entwicklung. Ist auf dem Novell-Netz (zusätzlich simuliert z.B. durch zippen großer Datenbestände mit WINZIP ) starker Datenverkehr, so habe ich die gleichen Probleme - obige Fehler beim Öffnen von Dateien, Schreiben und Schließen von Dateien, PDOXUSRS.LCK schreiben usw., auf "Application.terminate" wird trotz mehrfacher Versuche nicht reagiert, nach langer Zeit (1-3 Min.) reagiert das Programm wieder kurzzeitig (geht weiter in DB.PAS, ..), aber es geht nicht mehr normal weiter, wenn die Netzbelastung im Novell-Netz beendet ist.

Dies war nun ein langer Brief, aber vielleicht können Sie mir jetzt noch einen Tip für weitere Untersuchungen/Experimente geben? Beim Kunden werden heute als Experiment die PC's getauscht: Problemrechner mit normal arbeitenden PC.

mfg Kaise

[Andreas Kosch]

Hallo,

leider kann ich Ihnen auch nur das "Versuch-und-Irrtum"-Prinzip zur Fehlereingrenzung anbieten. Ich würde folgedes ausprobieren:

a) NET DIR zeigt auf ein <b>Wurzelverzeichnis</b> des NT-Servers (Bsp: <i>I:\</i>), d.h. alle Paradox-Datenbanken sollten exakt die gleiche Schreibweise und das gleiche NET DIR-Verzeichnis verwenden.

b) Alle Rechner verwenden eine feste Laufwerksverbindung (Laufwerksbuchstabe) für dieses NET DIR-Verzeichnis, die bereits beim Windows-Start aktiviert wird.

c) Wenn der Fehler immer am gleiche Installationsort und unabhängig von getauschten Rechner auftritt, würde ich die Länge des Netzwerkverbindungskabels variieren. Ich hatte schon mehrfach mit "Nullstellen" zu tun, die in einem BNC-Netz infolge von Fehlanpassungen entstanden sind. Derartige Unsymetrien sollten sich über ein erneutes Durchmessen der Netzwerkverkabelung ermitteln lassen.

d) Experimentelles Variieren der Netzwerkprotokolle (NetBEUI, TCP/IP) beim problematischen Rechner

[Wolfgang Kaiser]

Hallo,
danke für die neuen Tips.

Der Kunde ist dabei sein Netz zu testen. Übrigens der Rechnertausch ergab, daß es nicht am PC, sondern am Ort/Anbindung ans Netz liegen muß.
In meiner Firma tritt das Problem auch nicht mehr auf, nachdem einmal das Kabel vom NT-Server am Hub enfernt und neu aufgesteckt wurde. Also auch hier wahrscheinlich ein physikalisches Problem gewesen.
Dies sind aber die bzw. die noch zu ermittelnden Ursachen - mich ärgert, daß ich im Programm (z.B. ordentlich Programm beenden) nicht reagieren kann.

mfg Kaise

[Andreas Kosch]

Hallo,

wenn die Fehlernummern aus dem Bereich <i>OS Error not handled by IDAPI</I> kommen, rechntet die BDE nicht damit, so dass keinerlei Vorkehrungen für den Fall der Fälle getroffen werden :-