Announcement

Collapse
No announcement yet.

Fehlermeldungen im Interbase.log

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fehlermeldungen im Interbase.log

    Hallo!

    Vielleicht kann mir jemand helfen, die Herkunft folgender Fehlermeldungen im Interbase.log zu klären.

    <i><br>
    WNET/wnet_error: ReadFile end-of-file errno = 109<br><br>

    INET/inet_error: select in packet_receive errno = 10038<br>
    INET/inet_error: read errno = 10054<br>
    INET/inet_error: read errno = 10038<br>
    </i>

    Bei den unteren weiß ich nur, dass es sich um Fehler vom TCP/IP Protokoll handelt, aber nicht wie sie zustande kommen.

    Außerdem haben wir ab und an nochmal folgendes:

    <i><br>
    C:\Programme\InterBase Corp\InterBase\bin\ibserver.exe: terminated abnormally (-1)<br>
    Guardian starting: C:\Programme\InterBase Corp\InterBase\bin\ibserver.exe<br>
    </i>

    Gut, hier beendet sich der Server - aber aus welchem Grund? Das kommt zu den unmöglichsten Zeiten vor, auch wenn niemand mit der Datenbank verbunden ist!

    <b>HILFE!!</b>

    Greets,
    Holger

  • #2
    Hallo,

    zur Fehlernummer 109 hat <i>Brett Bandy</i> (Borland) vor einigen Monaten die folgende Erklärung als eMail verschickt: "<i>This is a known bug with current InterBase kits. The 109 error shows up after every disconnect of a netbeui connection. Even if you just connect to a database via netbeui and disconnect you will get the error. They are harmless except that:<br>
    1) they cause the log file to continuously grow<br>
    2) they may possible obscure meaningful 109 errors (ie network problems actually cause the 109 instead of the bug).</i>".

    Ich würde anstelle über NetBEUI über TCP/IP auf die Datenbank zugreifen, dann sollte das Problem verschwinden.

    Nicht ohne Grund gibt es den Guardian, der den "verstorbenen" InterBase wiederbeleben muss. Auch wenn niemand mit der Datenbank verbunden ist, läuft ab der Version 6 beim InterBase der Aufräumdienst ständig im Hintergrund. Als erstes würde ich versuchen, ob ein Backup, Umbenennen der GDB mit anschliessenden Restore des Backups die Symtome lindert

    Comment


    • #3
      Hallo Andreas!

      Also erstmal Dank für die Antwort.

      Wie wird denn festgelegt, über welches Protokoll ein Client/Programm sich mit der Datenbank verbindet? In unseren Programmen wird eigentlich der Datenbankpfad in TCP/ÌP-Notation festgelegt und in der Registry gespeichert

      -> servername:laufwerk:\pfad\datenbank.gdb

      Wenn das nicht ausreichend sein sollte erscheint mir die Auswahl des Protokolls schon irgendwie ein bißchen willkürlich!? Kann über NetBUI eigentlich auf die Datenbank zugegriffen werden, wenn keine Freigabe dafür besteht?

      Wir verwenden Interbase Version 5.6. Ein Backup - Restore fahre ich einmal pro Woche, da wir viele Datenbewegungen haben und die Datenbank sonst ins Unermessliche wachsen würde. Ab und an zieht sich der Server sehr viel Speicher und wird immer langsamer. Kann das an "gestorbenen" Transaktionen liegen? Wie kann ich die Anzahl der Transaktionen steuern, die in der Datenbank gehalten werden?

      Greets,
      Holge

      Comment


      • #4
        Hallo,

        beim InterBase legt die Syntax des Datenbankpfads den zu verwendenden Zugriffsweg fest:<br>
        a) lokalen Server: <i>D:\ib\employee.gdb </i> <br>
        b) TCP/IP: <i>Servername:\ib\employee.gdb </i><br>
        c) NetBEIU: <i>\\Servername\D:\ib\employee.gdb </i><br>

        Im Fall von NetBEUI wird keine Freigabe benötigt. Alle WNET-Einträge in der Log-Datei sind NetBEUI-Fehlermeldungen, daher muss mindestens ein Client (Tool) über diesen Weg auf den InterBase zugreifen.

        Die Anzahl der relevanten Transaktionen (Datensatzversionen) hängt vom verwendeten Isolation Level und der jeweiligen Transaktionsdauer ab

        Comment

        Working...
        X