Interbase Probleme

[Martin Klüver]

Wer kann mit dieser Fehlermeldung aus dem INTERBASE-LOG etwas anfangen :

SVR_multi_thread/RECEIVE: error on main_port, shutting down

(Korrespondierend bekommen wir von der BDE den Fehler :
Allgemeiner SQL-Fehler, Error reading from the Connection )

Gibt es so etwas wie eine Doku dieser Fehlermeldungen, die im LOG-File erscheinen ???

MfG Martin Klüver

[Martin Klüver]

Bei dem Versuch unter Interbase 5.6 Daten aus einer Datenbank A in eine Datenbank B zu importieren tritt folgendes Phänomen auf :

Der InterbaseServer protkolliert die folgende Fehlermeldung :
<b>Access violation : the code attempted to access a virtual address without privilege to do so</b>
diese Meldung wird so lange in das LOG-File protokolliert, bis
a. die Platte voll ist,
b. der Rechner neu gestartet wird , auf dem der SERVER läuft.
ein Beenden des IB-Dienstes (NT SP4) ist nicht möglich.

Der gleiche Spass unter IB 5.0 (NT SP4) gibt die folgende Fehlermeldung :
Server aborted abnormally (Errorcode -1)

Bei der Konvertierung geschieht folgendes :
1. Transaction Start auf Ziel DB
2. Batchmove aus SourceDatenbank für Tabelle A in TABELLE A' Zieldatenbank (ca. 55.000 Datensätze)
3. Query mit UPDATE in ZIELDATENBANK, es wird ein Feldwert in der Zieldatenbank um einen bestimmten Wert incrementiert, für alle Datensätze.

4. Transaction entweder Commit oder bei Exception Rollback

Wenn unter 3. statt mit einer Query mit einer TTable gearbeitet wird, und Datensatzweise in der Zieldatenbank upgedated wird, funktioniert der Spass.

HILFFFEEEEE, wer weiss was das ist

[Andreas Kosch]

Hallo,

das hört sich jedenfalls nicht gut an. Die Fehlermeldung <i>SVR_multi_thread/RECEIVE: error on main_port, shutting down</i> deutet darauf hin, das die TCP/IP-Verbindung abgebrochen ist und in Folge dessen die <b>Sockets</b>-Schnittstelle geschlossen wird.

Ich habe nur drei Fragen: <br>
1. Wird in der TQuery-Anweisung eventuell eine UDF aus einer DLL aufgerufen? <br>
2. Wenn in der BDE-Verwaltung die System/INIT-Einstellungen für <b>SHAREDMEMLOCATION</b> geändert werden (siehe Hilfeseite, dort wird der für NT übliche Bereich genannt), tritt dann der Fehler immer noch auf?<br>
3. Tritt der Fehler auch auf, wenn das Programm direkt auf dem Server gestartet wird und der interaktiv angemeldete User auch Administrator-Rechte hat?
&#10

[Martin Klüver]

Hallo,

zu 1: wir verwenden KEINE UDF's
zu 2: bringt nix :-(((
zu 3: Wir sind als lokaler Admininistrator an der entsprechenden Maschine angemeldet. Das Programm und die Datenbank befinden sich auf derselben Maschine.

<b>Aber : wenn wir in der BDE die folgenden Einstellungen ändern funktionierts :</b>
a. SERVERMODE = LOCAL
b. SQLPASSTHRU MODE = NOT SHARED

erst einmal vielen Dank für die spontane Reaktion !!

[Andreas Tengicki]

<b>SERVERMODE = LOCAL b. SQLPASSTHRU MODE = NOT SHARED </b>

<p>
Das ist aber die <b>Katastrophe</b> schlecht hin, weil dann die BDE
arbeitet und nicht der InterBase Server. ServerMode sollte unbedingt
SERVER sein.</p>

<p>Bei MultiThreading macht manchmal die BDE Probleme, verwendet Ihr eine Multiprozessor Maschine oder so, aber davon versteht Andreas (Kosch) mehr davon als ich</p&gt

[Andreas Kosch]

Hallo,

wenn sich das Programm und der InterBase auf der gleichen Maschine befindet, liegt ein Sonderfall vor. Wenn ich mich richtig erinnere, hängt in diesem Fall alles vom gewählten Eintrag für die BDE-Alias-Eigenschaft <b>SERVER NAME</b> ab. Wird die eigene IP-Adresse (127.0.0.1) nicht angegeben, greift der InterBase anstelle von TCP/IP auf Win32-API-Funktionen der Interprozess-Kommunikation (Pipes ?) zu. Und in diesem Fall gibt es mit hoher Wahrscheinlichkeit immer dann Schwierigkeiten, wenn der gleiche Prozess mehrere Sessions (Threads) verwendet.

Zum Test sollte einmal der Zugriff über <b>Server Name=127.0.0.1:C:\Database.GDB</b> ausprobiert werden.

Allerdings passt die Sockets-Fehlermeldung nicht zu meiner Vermutung :-(
&#10

[Wolfgang Bierl]

Hallo!
Ich habe ein ähnliches Problem, allerdings OHNE die BDE (Programmiert mit den IBX-Komponenten von Delphi 5.
Ich erhalte beim Speichern der Daten die Fehlermeldung "error reading data from the connection". Dummerweise kommt diese Fehlermeldung nur auf dem System des Kunden (100Mbit-Netz, Server Dual PIII-450MHz, NT4.0 SP5, TCP/IP-Protokoll, 256MB RAM im Server, IB5.5), die Daten werden aber ordnungsgemäß gespeichert.
Auf dem Entwicklungssystem (100Mbit-Netz, Server PII-400MHz, NT4.0 SP5, TCP/IP-Protokoll, 128MB RAM im Server, IB5.5) gibt´s keine Probleme.

Woran kann es liegen, wie kann ich das Problem so abfangen, daß ich wieder eine Verbindung zur Datenbank bekomme, ohne die Anwendung neu starten zu müssen?

Hilfe!
Dringend!

Gruß Wolfgang Bier

[Andreas Kosch]

Hallo,

meines Wissens nach ist bei derartigen Problemen nicht die BDE der Schuldige, sondern GDS32.DLL. Werden in der Anwendung mehrere Threads (Sessions) verwendet oder lässt sich die Anwendung von InterBase-Events informieren? Wenn ja, sollten die Probleme von den 2 parallel arbeitenden Prozessoren ans Licht gebracht werden. In diesem Fall tritt tatsächliche Multithreading auf, während bei einem Prozessor jeder Thread vom Scheduler nacheinander Rechenzeit erhält.

Es gibt von MS ein Tool, mit dessen Hilfe der Dual-Betrieb der Prozessoren für diese Anwendung ausser Kraft gesetzt werden kann (allerdings hatte ich noch nie mit solchen Maschinen zu tun)

[Stefan Guth]

Hallo,
ich habe ein Problem, daß ich bis jetzt nicht lösen konnte. Ich habe eine Tabelle Projekt, die aus Projekt_ID und Projekt_Name besteht.
Für weitere Tabellen verweise ich in den zugehörigen Formularen über eine LookUpComboBox auf die Tabelle Projekt. Öffne ich nun die ComboBox, so läßt sich nur ein Teil der Einträge selektieren, der andere Teil wird nicht angezeigt. Außerdem werden teileweise Einträge doppelt angezeigt. Selektiere ich hingegen die ComboBox ohne sie zu öffnen, kann ich alle Einträge ohne Problem mit den Pfeiltasten auswählen.
Komischerweise werden aber immer die richtigen ID_werte in die Tabelle eingetragen.
Hat irgendjemand schon ein solches Problem gehabt

[Bernhard Geyer]

Setze das Property CachedUpdates der zugrundeliegenden TTable bzw TQuery-Komponente für die Lookup-Liste auf TRUE! Das lößt das Problem (wie bei mir auch).

Ebenfalls kannst Du das Property ReadOnly auch auf TRUE setzen. Damit werden unter Umständen die Anzahl der DB-Zugiffe die BDE durch Auswahl in der LookUpComboBox ebenfalls verringern.

P.S. Das nächste mal bitte einen eigenen Diskussion-Punkt eröffnen(z.B. Probleme mit LookUpComboBox o. Ähnlich)

[Martin Klüver]

<b>Zum Thema reconnect einer abgestuerzten Datenbank :</b>
<p>
wenn irgendjemand feststellt, dass keine Verbindung mehr zur Datenbank existiert , DB explizit Closen und Thread starten, der zyklisch testet, ob ein beliebiges Statement ausgefuehrt werden kann. Wenn ja, dann Thread beenden und Event feuern, dass DB wieder da. Wir haben das so geloest, indem wir eine eigene DB-Komponente sowie eine eigene Query Komponente geschrieben haben, die dieses handling komplett automaitisiert.
<p>
<b>Wichtig:</b>
ein Reconnect ist mit TTableobjekten m.W. NICHT MOEGLICH, funktioniert nur mit TQueries (warum eigentlich)

MfG Martin Klueve

Hallo!
Neue Erkenntnisse zu dem am 9.12 beschriebenen Problem:
Es handelte sich entgegen der Angabe um ein NetBEUI-Verbindung (\\servername\Pfad\dbname.gdb)
Nach Umstellung auf eine TCP/IP-Verbindung (servername:Pfad\dbname.gdb) trat der <b>beschriebene</b> Fehler nicht mehr auf.<br>
Wir hatten dann das Problem, daß zwar die Anmeldung und die sonstigen Aktionen recht fix gingen, aber das Abmelden - ab der Anweisung"IBDatabase.conncted=False;" bis zum Verschwinden der Anwendung - 55(!)Sekunden dauert und während dieser Zeit die CPU-Belastung durch die Anwendung bei 99% lag.
Dieses Verhalten zeigte sich jedoch nicht auf jeder Arbeitsstation.

Nach jetzigem "Stand der Ermittlungen" tritt das Problem nur auf Systemen auf, die eine GDS32.dll verwenden, die neuer ist als Version 5.0.0.627 (mir der funktioniert es), mit den Versionen 5.5.0.742 und 5.6.0.29 tritt der eben beschriebene Fehler auf.
Ich installiere mir also das Update auf IB 5.6 und kopiere dann die GDS32 vom Interbase 5.0 rein?? Das kanns doch nicht sein!?

<b>Geht das auch anders ?</b> (Zumal ich noch nicht vollständig getestet habe, was <b>dann</b> alles passiert!

Anmerkung zur Antwort von Herrn Kosch: Ich habe mal irgendwo gelesen, dass Interbase geradezu optimal für Dual-CPU-Maschinen geeignet ist

[Andreas Kosch]

Hallo,

die hohe CPU-Belastung beim Verbindungsabbau ist mir bisher nur in Verbindung mit <b>TIBEvent</b> zu Ohren gekommen - in dem InterBase-Listserver hat Markus Kemper ([email protected]) dazu einige eMails verbreitet. Das Problem war nur bei bestimmten Kombinationen von GDS32.DLL und NT-SP reproduzierbar:

Zitat Markus Kemper:<i>
I have found that the problem (CPU spike) is isolated to the v5.5 (gds32.dll) client library. I have tested with the v5.0.0, v5.1.1 and a dev build of the v6.0.0 client and the problem does not reproduce.
</i&gt