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

Danke LouisLeon, werde ich mir mal näher ansehen.

Gruß

Rainer

 

Hallo Rainer,

falls das alles nichts hilft kannst Du ja noch kommerzielle Tools wie z.b. dieses hier testen. (Wurde auch von Sascha empfohlen *wink.gif*)

Gruß

LL

 

Das habe ich schon probiert, leider funktioniert es auf meinem Rechner nicht. ^^ Stürzt andauernd schon beim Start ab.

Da ist das Vertrauen in das Programm nicht wirklich gross. *wink.gif*

Werde mich aber mal durch andere Produkte kommerzieller Anbieter durchackern. Danke für den Tip.

Gruß

Rainer

 

Verständlich, wenn Du von der korrekten Installation deines Rechner überzeugt bist.
Ich habe es bisher noch nicht getestet, aber nachdem Sascha es gelobt hatte dachte ich ... *wink.gif*

Die Routine von Sascha hat auch nicht geholfen?
Josef's Vorschlag sollte aber, zumindest nach Bereinigung der Inkonsistenzen (durch den fehlerhaften DS), wieder ein verwendungsfähiges BE ergeben.

Ansonsten wird es ziemlich düster *wink.gif*

Gruß

LL

 

*lach* ... das der Rechner korrekt installiert ist, davon bin ich überzeugt (zumindest soweit das das Internet funktioniert, beim Absturz des Programmes war das Problem das es keine Internet-Connection zu Stande bekam und deswegen gecrashed hat). Aber nicht davon das er auch sauber funktioniert ... wie auch bei Vista 64 bit. ^^ Aber hab mir halt das System mit den größten Problemen draussen als Entwicklungsrechner rausgesucht.

Denke auch das das Programm gut sein mag, aber verträgt sich eben nicht mit Vista 64 bit. Wie soviele andere Programme auch. *wink.gif*
Und wer nicht hinbekommt das sein Programm aus Vista 64 bit eine Internet-Connection zu Stande bekommt dem traue ich auch nicht wirklich zu 400 USD wert zu sein. Frag jetzt bitte nicht ob ich auch wirklich eine aktive Internverbindung habe. ^^

Josef's Vorschlag funktioniert nicht. Selbst wenn ich nur die betreffende Tabelle alleine und ohne Beziehungen in eine neue leere DB importiere, habe ich das gleiche Problem beim betreffenden DS ... "Suchschlüssel wurde nicht gefunden" und keine Löschung des DS möglich. Werde da aber noch rumspielen um zu sehen was wir sonst noch so auffällt.

Saschas Version habe ich noch nicht probiert, da ich Acc 2007 habe und mich erst einackern muss wie ich seinen Vorschlag auf Acc 2007 umarbeite/-ändere.

EDITH: Werde mal gucken, habee jetzt das Programm Recovery ToolBox for Access gefunden. Zumindest die Demo-Version zeigt alle Tabellen inkl. Inhalte völlig korrekt an (auch den als korrumpiert identifizierten DS) und behauptet alles wieder herstellen zu können. Der Test ob es klappt muss mir wohl die knapp 50 USD wert sein.

Gruß

Rainer

 

Und die ganze mdb-Datei kopieren und dort die Beziehungen löschen, funktioniert auch nicht?

 

\@ Josef

Das habe ich noch nicht probiert.

Werde ich gleich mal austesten.

Gruß

Rainer

 

\@ Josef

So, gemacht ... und Problem besteht weiter. Also alle Tabellen inkl. Beziehungen in eine neue leere DB kopiert und dann alle Beziehungen per Hand rausgelöscht.

Danach werden Löschversuche auf den betreffenden DS immer noch mit dem Hinweis auf den fehlenden Suchschlüssel blockiert.

Und gerade eben die Meldung vom Kunden, dass die DB die wir vom Backup des Vortages aufgezogen haben nun die gleichen Probleme aufweist. Hab mir die DB schicken lassen und die wird von Access gleich beim Start als Inkonsistent moniert.

Tja, auffällig alleine ist das die DB seit Monaten problemlos läuft und jetzt erst nachdem der Kunde auch über Netbook (die billigen Dinger für 300 €) damit arbeitet die Probleme auftreten. Auffällig ist dabei, dass je nach System-Power das Netbook den Inhalt der Wechselfestplatte erkennt oder eben nicht erkennt (wenig Power = leeres Laufwerk wird im Datei-Explorer angezeigt). Befürchte ja fast das hier Schreibzugriffe mit nicht ausreichender Stromversorgung zu den Problemen führen.

Hab mir vom Kunden auch eine DB schicken lassen die aus einem Backup vor dem Einsatz auf dem Netbook stammt ... und das Teil bis mit Datensatz-Operationen malträtiert ... nix, funzt nach wie vor ohne Murren und Mucksen. Beim Kunden sind die Probleme vom aufgezogenen Backup vom Vortag nach 2 DS speichern und 1 DS ändern, danach schliessen und reparieren & komprimieren (lasse ich auf die BE's automatisch beim Schliessen des FE's ausführen) und beim Neustart eben das besagte Problem.

Bei meinem Developer-BE's die nun wirklich nicht geschont werden, seit Wochen kein Reparieren & Komprimieren mehr drauf ausgeführt und schon hundertfach bei hängender Anwendung abgewürgt über den Task-Manager das Problem noch kein einziges Mal gehabt.

Gruß

Rainer

 

... und nun noch die Schlüssel aus der Problemtabelle löschen.

 

\@ Josef

Habe in der Tabellenentwurfsansicht den PK für die Tabelle rausgenommen was ohne vorhandene Beziehung auch sauber funzte.

Danach wieder versucht den betreffenden DS zu löschen ... wiederum blockiert mit dem Hinweis auf den fehlenden Suchschlüssel.

Gruß

Rainer

EDITH: Falls es weiterhilft, führe ich eine SQL-Löschabfrage aus wird der Fehler mit der Nummer 3079 gekennzeichnet.

 

... nun könntest du noch ein Autowert-Feld einfügen und das zum PK machen.

BTW: bei Indexänderungen kann zwischendurch komprimieren vermutlich auch nicht schaden.

 

\@ Josef

Hab alles immer einmal ohne und einmal mit Komprimierung ausprobiert. ^^

Das mit dem Autowert-Feld werde ich jetzt mal gleich austesten.

Gruß

Rainer

 

Da ich ein Autowert-Feld eh drinnen habe (bilde den normalen PK aus einem Textstring + den Wert des AutoCounters des neu erstellten DS um 100% sicher zu gehen keine Dubletten zu haben ... bisserl umständlich bei der Neuanlage aber zuverlässiger als nur Textstring-PK), habe ich dieses zum PK gemacht.

Sowohl ohne als auch mit komprimieren ... gleiches Ergebnis beim Versuch den betreffenden DS zu löschen: Der Suchschlüssel wurde in keinem Datensatz gefunden.

Gruß

Rainer

P.S.: Hast Du Die Ergänzungen in meinem Post #23 gelesen?

P.S.S.: Nochmals vielen Dank vorab an Euch drei (Elmar, LouisLeon und Josef P.) für Eure Tips/Hinweisen zu meinem Problem.

 

Bezüglich vorhandenem Autowertfeld: probiere es trotzdem mit einem neuem Autowertfeld. Vielleicht ist gerade in diesen Felder der Defekt enthalten.

Ich frag mich schon die ganze Zeit, was mit Suchschlüssel gemeint sein könnte.
Kannst du andere Datensätze löschen?


bezüglich "automatischem Komprimieren"
... das führte ich nie durch, als ich noch Access/Jet-Backend-Dateien nutze. Dafür war mein Vertrauen in funktionierende Automatismen von Access noch nie groß genug. *biggrin.gif*

 

\@ Josef

1. Andere DS lassen sich problemlos löschen. Allerdings nur stichprobenartig ausprobiert.

2. Vorhandenen AutoCounter gelöscht, neuen eingefügt ... sowohl ohne als auch mit ausgeführtem reparieren & komprimieren nach wie vor gleiches Thema: Löschung des DS wird mit Hinweis auf fehlenden Suchschlüssel blockiert.

3. Meine Recherchen im Internet haben ergeben das diese Meldung erscheint, wenn beim Zugriff auf ISAM SEEK kein übereinstimmender Index gefunden wird. I.d.R. soll das auftreten wenn es beim Schreibzugriff auf die DB Unterbrechungen gegeben hat. Wenn ich die englischen infos richtig übersetzt habe, gibt es eine ISAM SEEK zu jeder Tabelle und die steuert sämtliche DS-Operation weil sie für die Struktur der Tabelle zuständig ist. Mal frei von mir interpretiert: Beim DS Schreiben gab es eine Unterbrechung und deswegen existiert der angezeigte DS nicht in der ISAM SEEK (was das auch immer genau sein mag, nehme an Strukturdarstellung/-abbildung auf Binärcode-Ebene) der Tabelle und deswegen sind Zugriffe/Operationen mit dem DS nicht mehr möglich. Wahrscheinlich sehr laienhaft formuliert aber weiter bin ich nicht vorgestossen. *wink.gif*


4. Naja, da alle immer bei Problemen gleich Fragen ob man schonmal Komprimieren & Reparieren ausgeführt hat dachte ich das dieser Automatismus nicht verkehrt wäre. Vor allem wollte ich damit verhindern das zuviel unnötiger Ballast durch gelöschte Einträge mit rumgeschleppt wird. Habe auch von diesem Automatismus noch nichts negatives gelesen ... im Gegensatz zu den meisten anderen Automatismen die Access bietet. ^^

Morgen geht es für mich weiter, heute Schnauze voll. Würde mich freuen wenn Du/ihr weiter dabei seid ... hat mir heute schon unheimlich geholfen.

Gruß

Rainer