Announcement

Collapse
No announcement yet.

Fehlermeldungen von gbak.exe

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

  • Fehlermeldungen von gbak.exe

    Hallo,

    Was kann ich gegen folgende Fehlermeldungen von gbak (interbase 5.6) unternehmen ?

    1) ERROR: arithmetik exception, numeric overflow, or string truncation<br>
    2) ERROR: Cannot transliterate character between character sets<br>
    3) ERROR: gds_$send failed

    Der Fehler tritt beim Rücksichern einer Tabelle mitten in der Datenbank auf.

    Das Programm läuft sonst ohne Probleme.

    Im Alias wird der Treiber WIN-1252 verwendet.

    Vielen Dank für Hilfe<br>
    Helmut

  • #2
    Hallo!

    Zu diesem Fehler kommt es wenn in einer Tabelle Daten enthalten
    sind die nicht dem eigentlichen Feldvorgaben entsprechen.
    GBak müßte eigentlich auch an genau dieser Tabelle beim Rücksichern
    halt machen so das die Fehlerquelle schnell lokaliesiert werden
    kann. Eine ganz unangenehme Nebenwirkung der IB ist es eine "defekte
    Datenstrucktur" zu sichern (ohne zu meckern) aber eine Rücksicherung
    nicht mehr zuzulassen.

    Ist an der Tabellenstrucktur was geändert worden? wurden Char in VChar
    geändert? sind Umlaute enthalten?

    kannst mich gerne direkt kontakten unter [email protected]

    gruß jürge

    Comment


    • #3
      Hallo,

      danke für die Antwort.

      Die Tabellen sind seit der Erstellung mittels TQuery, welche aus Testgründen sehr oft erfolgt, nicht geändert worden.

      Es gibt Umlaute. Ich verwende deshalb den Treiber WIN-1252 im Alias. Im Programm selbst habe ich keine Probleme mit den Umlauten.

      Ich kann zwar feststellen, bei welcher Tabelle GBak das Rücksichern verweigert, kann aber nichts aussergewöhnliches feststellen.

      Was tut man in so einem Fall, wenn dies beim Kunden passiert ????

      Auf Interbase, welches anscheinend solche Probleme aufwirft verzichten ?

      Gruss<br>Helmu

      Comment


      • #4
        Hallo,

        beim InterBase ist es immer eine gute Idee, sich nach dem Anlegen einer Datenbankstruktur bzw. nach jeder Strukturänderung mindestens einmal über BACKUP/RESTORE davon zu überzeugen, dass die Wiederherstellung klappt. Es gibt einige Konstellationen, bei denen man sich ansonsten selbst ins Knie schiesst.

        Wenn man das allerdings erst beim Kunden zum ersten Mal bemerkt (weil vorher nie ein Restore abgearbeitet wurde), wird man ohne partitiellen Datenverlust nicht heil aus der Sache herauskommen

        Comment


        • #5
          Hallo,

          <b>Frage 1:</b><br>
          Gibt es wirkliche keinerlei Hinweise, von Inprise o.a., welche Situationen derartige Fehler beim Rücksichern auslösen und was man dagegen tun kann ?

          Wenn im Programm alles ohne Fehler läuft, wie soll man da die Ursache finden ?

          <b>Frage 2:<br></b>
          Gibt es Fremdprogramme oder Tools, mit denen man eine mit gbak erstellte Sicherungsdatei analysieren bzw. rücksichern kann ?

          <b>Frage 3:<br></b>
          Sind in der Interbase Datei *.gdb alle Informationen enthalten ? <br>
          Oder hält Interbase an anderen Orten noch Informationen über die Datenbank und die darin enthaltenen Tabellen, Generatoren usw. parat ?

          Wo werden die Informationen über Transaktionen, die verschiedenen Versionen der Datensätze usw. gehalten - In der Datenbank selbst ?

          Falls alles in *.gdb enthalten wäre, könnte man doch das 1 File der Datenbank mit herkömmlichen Explorer-Methoden sichern und rücksichern ?

          Hier könnte man, abgesehen von der durch die Rücksicherung vorgenommenen Bereinigung, zumindest eine lauffähige Version der Datenbank restaurieren.

          Gruss<br>Helmu

          Comment


          • #6
            zu 1) soweit ich weis nicht, ggf http://www.ibphoenix.com/

            zu 2) keine Ahnung

            zu 3) alle Infos sind in der gdb-Datei. Aber ein Zugriff auf diese Datei, während InterBase damit arbeitet, *auch wenn er lesend ist* ist ggf in der Lage die DB zu beschädigen. Also ist dabei Vorsicht zu wahren.

            gdb-Dateien am besten nur kopieren, wenn der InterBase Server nicht aktiv ist

            Comment


            • #7
              Hallo,

              zu Frage 1: <br>
              In meinem Buch <i>Client/Server-Datenbankentwicklung mit Delphi</i> beschreibe ich einige dieser problematischen Fälle. Generell sind die folgenden Teile "gefährlich": <br>
              a) Umlaute in CREATE DOMAIN oder sonstigen Schema-Deklarationen<br>
              b) Explizite PLAN-Anweisungen in Triggern und Stored Procedures<br>
              Nur dann, wenn die Datenbank über Backup gesichert, als Datei umbenannt und dann über Restore wiederhergestellt wird, schafft man sich Gewissheit.

              zu Frage 2: <br>
              Ist mir nicht bekannt, glaube ich jedoch nicht. Ich würde bei Borland nachfragen, ob dort das (kostenpflichtig) korrigiert werden kann.

              zu Frage 3: <br>
              Ja - in der GDB-Datei sind alle Daten. Nur die Benutzerkonton stehen in der isc4.gdb. Der InterBase benötigt dank seiner Multigenerationen-Architektur im Gegensatz zu anderen SQL-Servern keine spezielle Logdatei, sondern kommt mit einer internen Hilfstabelle für alle aktiven Transaktionen aus.

              Ab dem InterBase 6 ist das Sichern der Datei nur dann sicher, wenn die Datenbank mit einem ReadOnly-Attribut gekennzeichnet wurde. Ansonsten muss man immer damit rechnen, dass der separate Garbage Collection-Thread noch am Werkeln ist und jeder direkte Zugriff auf die Datei Müll produziert. Wer ganz sicher gehen will, hält den Guardian und den InterBase als Dienst an, bevor er die Datei kopiert

              Comment


              • #8
                Vielen Dank Herr Kosch für die Informationen!

                Helmu

                Comment

                Working...
                X