Office: (Office 2007) Ideen für Rettung eines korrupten BE's?

Hi an Alle!

Hat jemand von Euch einen Tip wie man eine korrupte DB repariert?

Habe das Problem das sich ein Kunde das Datenbank-Backend geschossen hat, weil er während des Schreibzugriffes auf das Backend den Saft vom Laptop verloren hat.

Dadurch kommt bei einem DS die Fehlermeldung "Der Suchschlüssel wurde nicht gefunden" und der DS kann weder bearbeitet, noch gelöscht noch sonstwas kann mit ihm gemacht werden.

Die kompletten Tabellen in eine neue leere DB übernehmen hat das Problem auch nicht gelöst und ein reparieren + komprimieren auf das BE durch zu führen hat auch nicht geholfen. Der DS bleibt korrupt.

Jetcomp.exe funktioniert ja nicht mehr auf Access 2007 DB's (oder sehe ich da was falsch?).

Von daher nun mein Problem ... jmd eine idee dazu oder eine Empfehlung für ein gutes/effektives Tool das so ein Problem wieder lösen kann?

Der Kunde hat Gott sei Dank die eingebaute Backup-Routine brav genutzt und kann daher mit dem Backup weiter arbeiten. Mir geht es vorrangig um das Thema kann man so ein beschädigtes BE wieder herstellen und wenn ja wie oder womit. *wink.gif*

Gruß

Rainer

:)

 

Also nur ein(!) Datensatz, nicht die ganze DB ist korrupt/defekt.
Wie sieht der DS denn in der Datenblattansicht (also der Tabelle) aus?
Stimmen die Beziehungen? (für den Fall, dass der DS in einer Tabelle mit Beziehungen zu anderen Tabellen untereinander) steht.

 

\@ elmar

Der DS sieht in der Tabellen-Sicht absolut normal und unauffällig aus.

Ob noch andere DS korumpiert sind kann ich nicht sagen, da bei Start des Front-Ends die Daten im Backend erstmal entschlüsselt werden müssen (die BE's werden zwecks Datensicherheit nach jedem beenden des Frontends sequentiell verschlüsselt).

Und genau bei diesem DS bleibt die Entschlüsselungsroutine hängen und blockiert komplett. Ein weiter kommen zum nächsten DS ist nicht möglich, da rst.MoveNext nach diesem DS nicht weiter geht.

Stichproben haben allerdings ergeben das ich aus den nachfolgenden DS problemlos DS raus löschen kann. Allerdings eben den betreffenden DS nicht.

Die grundlegenden Beziehungsschemen stimmen alle noch, da bei fehlender/falscher/schadhafter Beziehung alle anderen DS genauso davon betroffen wären.

Die Fehlermeldung wird ja i.d.R. ausgegeben wenn ISAM SEEK ausgeführt wird und kein übereinstimmender Wert im Index gefunden wird. Sowas kann auftreten wenn die DB nicht korrekt geschlossen wird, bzw. Schreibzugriffe gestört/unterbrochen werden. Passt auch gut zur Schilderung vom Kunden, dass während er einen DS speicherte der Saft vom Schlepptop weg war.

Gruß

Rainer

 

Wenn das BE seperat geöffnet wird, läßt sich dann der "Problem-DS" löschen?

 

\@ Elmar

Hatte ich doch geschrieben. *wink.gif*

Nein, er lässt sich nicht löschen weder vom FE aus noch direkt aus dem BE. Auch Löschversuche über den Umweg ein DELETE-Abfrage direkt im BE auszuführen schlugen fehl (war eigentlich klar, aber sicherheitshalber probiert).

Gruß

Rainer

 

Hm, leider fällt mir zur Lösung derzeit kein Tipp mehr ein.
Hatte das Problem mal vor einiger Zeit unter AC2000/AC2003, allerdings war keine Verschlüsselunsroutine im Spiel.

PS: fällt mir grad noch ein...

Was passiert, wenn Du mittels Anfügeabfrage alle DS, aber ohne den korrupten DS, in eine Tabelle gleicher Definition transportierst?
Läßt sich die Tabelle mit den korrupten DS löschen, um dann die Tabellen-Kopie umzubenennen?

 

Genau das Thema wollte ich umgehen. Es handelt sich um eine Haupttabelle mit extrem viel Beziehungen und um diese Tabelle dann zu löschen, muss ich erst die Beziehungen killen und nach erfolgreichem kopieren/löschen dann alle Beziehungen wieder herstellen. Das wäre ein riesen Act.

Komplett alles kopieren in eine neue leere DB funzt auf jeden Fall nicht, der korrumpierte DS wird mit der Korrumption übernommen (möchte auch nicht ausschliessen das es nicht noch weitere korrumpierte DS gibt).

Daher ja auch meine Frage ob jmd ein gutes Repair-Tool, am besten eines was auch die Index-Tabelle repariert/neu schreibt, kennt.

Gruß

Rainer

 

ein Decompile war ohne Erfolg? Kann ich fast nicht glauben *wink.gif*

Die Tabelle ist doch in "unverschlüsseltem" Zustand, oder?

Gruß

LL

 

\@ Louisleon

Die Tabelle ist in dem Sinne eh immer unverschlüsselt, einzig und alleine sind einige Feldinhalte verschlüsselt.

Du meinst also ich sollte auch erstmal die Feldinhalte entschlüsseln bevor ich ein Decompile auf das BE durchführe?

Problem ist das genau das nicht geht. Denn die Entschlüsselungsroutine bricht immer exakt bei dem korrumpierten DS ab. Selbst ein Error Resume Next hilft nichts, die Anweisung wird dann zwar übersprungen aber rst.MoveNext für die Schleife funzt nicht und bleibt konstant auf dem DS kleben.

Gruß

Rainer

 

Decompile wird vermutlich nicht helfen, da der Defekt anscheinend in der Tabelle und nicht im kompilierten Code liegt.

@Rainer: verstehe ich dich richtig: das Verschlüsseln ändern nur den Inhalt von Textfeldern? ... dann musst du imo auch nicht entschlüsseln, bevor du die Tabelle reparierst, da der Inhalt des Textfeldes Access/Jet ziemlich egal sein wird.

Hast du schon in einer Kopie des BE getestet, ob das Entfernen des PK und das anschließende Erstellen helfen würde?
BTW: Welchen Datentyp verwendest du für den PK?

Hatte nicht Sascha einmal eine Methode vorgestellt, wie man Indizes reparieren kann?

 

Stimmt, da war mal was kann mich auch vage dran erinnern!

BTW ich ging bisher davon aus, das Decompile nicht nur den binären Code neu generiert sondern auch die Tabellenstrukturen neu indiziert.

Gruß

LL

 

\@ Josef P.

Richtig, es werden nur Feldinhalte verschlüsselt. Einfach eine zusätzliche Sicherheitsmaßnahme zum relativ einfach zu knackenden Passwortschutz von Access.

Ich benutzt für die PK's den Datentyp Text.

Werden mal gucken ob ich den PK rausnehmen und ihn anschliessend wieder erstellen was hilft.

EDITH: Nein, kann den PK nicht rausnehmen da die Tabelle eine Mastertabelle in mehrere Beziehungen ist.

Die Methode von Sascha würde mich brennend interessieren? Irgendeinen Link oder ein Stichwort/Ort zum gezielten Suchen dazu?

@ LouisLeon

Habe nochmals Decompile ausgeführt (Passwortschutz natürlich vorher rausgenommen) und im Anschluss an den Start mit Decompile dann noch reparieren/komprimieren ... ändert nix am Problem.

Gruß

Rainer

 

Na und? ... in einer Kopie kannst du doch die Beziehungen entfernen, damit du wenigstens testen kannst, ob das Problem durch das Neuerstellen des Index behoben würde.
Und falls es klappt, ist eine VBA-Routine, die die Beziehungen ausliest, irgendwo speichert, den PK neu erstellt und dann die Beziehungen wieder erzeugt, schneller durchgeführt, als eine Wochenlange suche nach einer Lösungsmöglichkeit, ohne die Beziehungen neu erstellen zu müssen. *wink.gif*

Leider nicht. Ich glaube zwar, dass Sascha das hier im Forum erwähnte, mir fallen aber keine Stichwörter ein, mit denen eine Forumssuche erfolgreich sein könnte.

 

Okay, okay ... da hast Du natürlich eindeutig Recht.

Werde es mal ausprobieren.

Gruß

Rainer

 

Ich glaube es war dieser hier!

Gruß

LL