Announcement

Collapse
No announcement yet.

Verlust der AutoInc-Daten, wie weiter?

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

  • Verlust der AutoInc-Daten, wie weiter?

    Hallo Andreas, du hast in einer Antwort geschrieben, daß du als Primärschlüssel die ID als Autoinc-Feld nutzt. Bei einem Crash und einer anschließenden Reparatur würden die AutoInc-Felder neu nummeriert. Das würde doch bedeuten, daß das ganze Programm nicht mehr funktionierst. Da ich haargenau nach demselben Prinzip arbeite, kommt nun meine Frage:
    Wie fängst du das ab?

    mfg Klaus-Peter

  • #2
    <b>Symtome</b>

    - Ein neuer Datensatz kann im Anwendungsprogramm nicht gespeichert werden (Fehlermeldung: »Indexfehler«) <br>
    - Ein neuer Datensatz kann ich in der Datenbankoberfläche nicht mehr gespeichert werden, in der Statuszeile wird ebenfalls die Fehlermeldung »Indexfehler« angezeigt. <br>
    - Das Datenbank-Prüfprogramm »TUTIL32.EXE« zeigt keine Beschädigung in der Datenbank an!<br>
    - Ein Rebuild der Tabelle mit »TUTIL32.EXE« beseitigt das Problem nicht!

    <b>Fehlerbeseitigung</b>

    Für den Fall, daß ein Backup nicht zur Verfügung steht, kann eine neue Datenbank angelegt werden.

    Schritt 1: Verzeichnisse und Aliase anlegen

    Sowohl für die alte (beschädigte) Datenbank als auch für die neu aufzubauende Datenbank muß jeweils ein eigenes Verzeichnis sowie ein eigener Alias vorhanden sein.

    Schritt 2: Neue Tabellen mit importierter Struktur anlegen

    In der Datenbankoberfläche wird das Arbeitsverzeichnis auf das Verzeichnis für die neue Datenbank gesetzt. Anschließend wird eine neue Tabelle mit der aus der alten Datenbank importierten Datenstruktur angelegt. Kann die neue Tabelle nicht ohne Fehlermeldung abgespeichert werden (zum Beispiel falls »Ungültiger Dateiname« angezeigt wird), so muss ein vorhandener Eintrag der referenziellen Integrität über die Schaltfläche »Ändern« nur neu bestätigt werden (d.h. die in der rechten Listbox angezeigte Datei muss neu ausgewählt werden). Die Bezeichnung bleibt dabei die gleiche - die Verknüpfung wird für das aktuelle Verzeichnis nur neu angelegt. Trotzdem können die somit zusammenhängenden Tabellen später in das Originalverzeichnis problemlos zurückkopiert werden - die Prüfung findet nur beim Neuanlegen der Tabelle statt.

    Schritt 3: Neue Tabellen mit dem Inhalt der alten Tabellen füllen

    Direkt in der Datenbankoberfläche wird über SQL (<i>INSERT INTO ":NEU:Test.db" SELECT * FROM ":ALT:Test.db"</i>) der Inhalt der alten Tabelle in die neue (noch leere) Tabelle kopiert. Damit wird sowohl die Zieltabelle als auch die Quelltabelle über den vorangestellten BDE-Alias eindeutig gekennzeichnet. Achtung! Wenn die Zieltabelle als Primärschlüssel ein Feld vom Typ Autoincrement verwendet, bekommen alle Datensätze einen neuen, durchnummerierten Primärschlüsselwert. Damit muß der Fremdschlüsselwert in einer abhängigen Tabelle Datensatz für Datensatz nachträglich geändert werden! Es ist daher sinnvoll, die aktuellen Verknüpfungen in einer Abfrage <b>vorher</b> zusammenzustellen und in einer separaten Ergebnistabelle zu speichern.

    Schritt 4: Fremdschlüssel-Werte anpassen

    Das ist der unangehme Teil der Angelegenheit, indem die Datensätze der "geretteten" Hilfstabelle mit den neuen Tabellen abgelichen wird.

    P.S: Ich greife daher <b>immer</b> zum letzten Backup, und muss daher nur im Notfall (kein Backup vorhanden) die Daten auf die harte Tour zusammenflicken

    Comment


    • #3
      Danke für deine Antwort,
      das würde ja bedeuten, daß ich das Backup und das Wiederherstellen programmtechnisch realisieren kann. Das Einzige, was mich bisher davon abgehalten hat war die Frage:
      Wie kann ich beim Start des Programmes erkennen, ob eine Beschädigung der Tabelle vorliegt, so daß ein Backup geladen werden kann.

      mfg Klaus-Pete

      Comment


      • #4
        Hallo,

        diese Entscheidung würde ich in jedem Fall dem Anwender überlassen, wobei die automatische Frage "Backup zurückspielen" nur dann angezeigt werden sollte, wenn bereits beim Öffnen der Tabelle eine Exception ausgelöst wird

        Comment


        • #5
          Danke für die Antwort.
          Wenn ich mehrere Tabellen in der 3.Normalform über AutoInc-ID's miteinander verbinde und eine davon ist schlecht und der Kunde versucht die Selbstreparatur, dann bin ich aber arm dran.
          Ich glaube es ist besser, sich die eindeutigen Nummern selbst zu erstellen und zuzuweisen.

          mfg Klaus-Pete

          Comment


          • #6
            siehe Entwickler Forum\Delphi\Datenbankentwicklung\Kundennummer vergebe
            Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.

            Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!

            Comment

            Working...
            X