DataBase - Nicht erkennbares Datenbankformat

Asked By Susann Markward

28-Jan-10 04:31 AM

X-Post nach m.p.d.v.d und m.p.d.a mit einem FUp2 nach m.p.d.v.d

Hallo,

ich habe einen Kunden, der ein Problem mit einer MS Access Datenbank von
mir hat.

Ich habe eine VB6-Anwendung, welche lesend und schreibend auf eine MS
Access-Datenbank zugreift. Nun hat der Kunde Probleme mit dieser
Datenbank und ich auch. Der Kunde hat mir diese zugeschickt. Wenn ich
versuche diese zu ?ffnen, bekomme ich die o.g. Fehlermeldung:

Nicht erkennbares Datenbankformat "C:\Programme\MeinProgramm\data'

Frage:
Kann man irgendwie, oder irgend woran erkennen, warum diese Datenbank
nun pl?tzlich korrupt und nicht mehr lesbar oder schreibbar ist?

Mit freundlichen Gr??en
Susann

28-Jan-10 04:41 PM

Hallo Susann,

typischerweise hat irgendein ein Schlaubeutel vor Ort die Datenbank
mit einer neueren Access-Version ge=F6ffnet und im Dialog best=E4tigt,
dass er sie konvertieren will. Wer liest schon die Warnung, dass alle
anderen dann ausgesperrt sind?

tsch=F6, Lorenz

28-Jan-10 04:47 AM

Hallo, susann


Schau mal bei Thilo Immel vorbei :

http://www.access-rettung.de/info.htm

Da findest Du nicht nur Erl?uterungen und Links zum Thema - sondern im
Zweifelsfalle auch Hilfe, wenn es an einer aktuellen Datensicherung mangeln
sollte.


--
Gruss
Jens

FAQ: http://www.donkarl.com

28-Jan-10 04:58 AM

Hallo Susann,


dies kommt zu 90% der Fälle durch nicht korrektes Abmelden von der DB
durch z.B. Hardwaredefekt, Spannungsausfall, Netzwerkaussetzer, brachiales
Runterfahren etc..
Ich hatte das bei meinen Kunden auch schon mal dieses Problem, weil sie ein
MS-Update mit anschließendem Neustart gefahren haben, obwohl noch Benutzer
von diesem PC aus oder, was noch schlimmer ist, von einem anderen PC im
Netzwerk, mit der DB verbunden wahren.

Um eine solche DB zu reparieren gibt es ein fertiges Prog. "JETCOMP.exe".
Ich habe mir  bzw. für meine Kunden ein eigenes Reparaturprog. geschrieben.
Der Kern meines Reparaturprogs ist:
CompactDatabase SourceName, DestName, , , ";PWD=" & Passwort


Viele Grüße
Wilfried

28-Jan-10 05:15 AM

Ich sollte vielleicht noch erwähnen, dass ich nicht die
CompactDatabase-Methode (JRO) meine, diese schafft es nicht eine
solche DB zu reparieren.
Das DAO CompactDatabase dagegen schon. Bis jetzt konnten damit
alle DB, die die genannte Fehlermeldung erzeugten, repariert werden
(was zum Glück nur selten notwendig war).

Viele Grüße
Wilfried

28-Jan-10 07:36 AM

hallo Susann,

Im Normalfall ist die Datenbank tot. Du kannst es noch mit JETCOMP
probieren:

http://support.microsoft.com/kb/295334/de

Das Warum l??t sich nicht erkennen. Ich w?rde im Programm ein
automatisches Backup beim Programmstart oder -ende einbauen:

http://www.visualbasic.happycodings.com/Database_SQL_Stuff/code7.html


mfG
--> stefan <--

28-Jan-10 10:03 AM

Hallo Susann,


Geschieht dies in einem Mehrbenutzerbetrieb oder greift nur
ein einziger Benutzer zu?


Die *.mdb ist also beschädigt.



Es gibt eine Reihe von Möglichkeiten, eine *.mdb zu
beschädigen. Deshalb auch meine Frage nach dem
Mehrbenutzerbetrieb.

Unter

http://support.microsoft.com/kb/273956/de

gibt es das Program JETCOMP.exe mit dem sich beschädigte
Jet-Datenbankdateien der Versionen 3.x und 4.x in vielen
Fällen reparieren lassen.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

28-Jan-10 01:51 PM

Hallo,



Um welche Jet-Version geht es eigentlich? 3, 3.5, 4, ACE? Falls Lorenz'
Theorie stimmt, versuch mal, mit der jeweils naechst-hoeheren DAO-Version
zuzugreifen.

Gruss - Peter

--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com

29-Jan-10 05:16 PM

Hallo,

*Peter G?tz* schrieb am 28.01.2010 16:03:

Nur ein Nutzer. Mehrbenutzerbetrieb wird nicht unterst?tzt.



Ja, wie ich mittlerweile auch gelernt habe, ist sie irreparabel
besch?digt. Ich _vermute_ , dass sich w?hrend eines Schreibzugriffs ein
Stromausfall ereignete.



Habe ich probiert. Leider ohne Erfolg.

Aber es ist nicht weiter schlimm. Es handelt sich nicht um Daten, die
sich nicht erneut gewinnen lassen.

Danke
Susann

29-Jan-10 05:35 PM

Hallo,

*Susann Markward* schrieb am 28.01.2010 10:31:

Vielen Dank f?r die Hinweise. Wie ich bereits Peter antwortete, handelt
es sich nicht um Daten, welche sich nicht noch einmal wiederbeschaffen
lassen.

Ich ?berlege nun nur, wie ich es zuk?nftig verhindern kann. Da ich
jedoch nicht genau wei?, wie es zustande kam, ist es ziemlich schwierig.
Daher fragte ich auch, ob man im Nachhinein mit vertretbaren Aufwand
erfahren k?nnte, wie es dazu kam. Scheinbar nicht, ohne ein
Datenrettungsunternehmen zu beauftragen. Das steht jedoch in keinem
Verh?ltnis zu den verlorenen Daten.

Wir haben heute etliche Versuche gefahren, wo wir dem PC einfach den
Strom 'abdrehten'. In keinem der F?lle kam eine derart besch?digte Datei
heraus. Einmal haben wir eine DB erhalten, die sich mit MS Access nicht
?ffnen lie?. Hier half jedoch "JETCOMP.exe" weiter, was es bei der
Kunden-Datenbank jedoch nicht tat.

Um diesem Vorfall vorzubeugen, habe ich mir Folgendes ?berlegt:
Man schreibt einfach in zwei identische Datenbanken nacheinander.

1) Messwert erhalten
2) ?ffne DB1
3) Schreibe Wert in DB1
4) Schlie?e DB1
5) ?ffne DB2
6) Schreibe Wert in DB2
7) Schlie?e DB2

Ist nun eine Datenbank nicht mehr zu ?ffnen, habe ich die andere, aus
welcher ich die korrupte DB wiederherstelle.

Wie denkt ihr dar?ber?

30-Jan-10 04:08 AM

Hallo Susann,


Eine *.mdb sollte in jedem Fall regelmässig komprimiert
werden, wenn an ihr Änderungen vorgenommen worden sind.
Mit der CompactDataBase-Methode der JetEngine ist das
kein übermässig grosses Procedere.

dim strCnnSrc as string
Dim strCnnDest as string

strCnnSrc = ....Connectionstring für Quelledatei
strCnnDest = ...Connectionstring für Zieldatei

JetEngine.CompactDatabase strCnnSrc , strCnnDest



Eindeutig festzustellen, wie es dazu kam, dürfte sehr
schwierig bis unmöglich sein.

....schnipp...


Je nach Belastung liefert die Stromversorgung des
Rechners nach so einem "Abdrehen" noch einige
Millisekunden Strom, was für einen "sauberen"
Abschluss einer gerade laufenden Schreiboperation
noch reichen kann. Es wäre also eher Zufall, wenn sich
auf diese Weise der Fehler reproduzieren liesse.

... schnapp...


Das ständige Öffnen und Schliessen einer *.mdb hat u.a.
zur Folge dass dabei auch jedesmal in die zugehörige
*.ldb geschrieben werden muss bzw. diese neu angelegt oder
gelöscht werden muss. Ein nicht unbeachtlicher Aufwand
mit div. nachteiligen Folgen.


Einbenutzerbetrieb:
Ein CompactDataBase beim Programmstart wäre vermutlich
relativ einfach zu implementieren. Dabei fällt automtisch eine
Sicherungskopie der *.mdb an. Genauer gesagt, die alte bisherige
*.mdb wird zur Sicherungskopie und die neue komprimierte *.mdb
wird zur Arbeitskopie. Damit wäre schon mal zumindest bei
jedem Programmstart sichergestellt, dass die bis dahin
vorhandenen Daten gesichert sind.

Bei einem Mehrbenutzerbetrieb müsste das CompactDataBase
beim ersten Öffnen der *.mdb erfolgen. Ob und von wem eine
*.mdb bereits geöffnet ist, lässt sich wie in

www.gssg.de -> Visual Basic -> VBclassic
-> Datenbank
-> ADO DemoMu 2002
[clsGSADOData.cls / FunctionGetUserList]

feststellen. Ansonsten einfach versuchen die *.mdb exklusiv
zu öffnen. Hat noch kein anderer Benutzer die *.mdb geöffnet,
gelingt das exklusive Öffnen und die *.mdb kann via
CompactDataBase komprimiert werden. Ist die *.mdb
bereits anderweitig geöffnet, löst der Versuch sie exklusiv
zu öffnen einen Fehler aus, auf den entsprechend reagiert
werden kann.

Darüber hinauskann es auch beim Einbenutzerbetrieb nicht
schaden schreibende DB-Zugriffe konsequent mit

JetEngine.RefreshCache Cnn

abzuschliessen um damit in jedem Fall das sofortige
Wegschreiben des Datenpuffers der JetEngine zu
erzwingen und so Datenverlusten vorzubeugen.
Als Beispiel hierfür kann

www.gssg.de -> Visual Basic -> VBclassic
-> Datenbank
-> ADO DemoMU 2002

30-Jan-10 08:29 AM

Hallo,


Wie es dazu kam, wird dir das Datenrettungsunternehmen eher nicht sagen
koennen, wohl aber, was von den Daten gerettet werden kann.

Der bereits genannte Wayne Philips (
http://www.everythingaccess.com/accessdatabaserepair.htm ) liefert dir
Informationen pro Objekt, speziell ob und wieviel wiederhergestellt werden
kann und auch die Kosten dafuer. Erfahrungsgemaess ist die Inanspruchnahme
eines solchen Services die guestigere Loesung zur Wiederherstellung der
Daten, wenn man nicht auf aktuelle Backups zurueckgreifen kann.

Aber wie bereits erwaehnt, wenn es dir nur um Ursachenforschung geht, ist
das die falsche Adresse.

Eine haeufige und nachstellbare Ursache sind Netzwerkprobleme. Es reicht
manchmal schon, waehrend eines Updates das Netzkabel zu ziehen, um das
Backend abzuschiessen.

Gruss - Peter

--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com

15-Feb-10 06:19 AM

Hallo,

in diesem Zusammenhang noch eine Frage.

Ich m?chte nun eine Routine schreiben, welche vor dem Start der Software
?berpr?ft, ob sich alle DBs in einem validen Zustand befinden und auch
nur dann die Software startet.

Kann ich davon ausgehen, dass, wenn ein Feld einer Tabelle der DB lesbar
ist, die gesamte DB in Ordnung ist?

Mit freundlichen Gr??en
Susann

15-Feb-10 08:45 PM

Hi Susann,
nein, das kannst du nicht. Es k?nnen z.B. Felder, die nicht leer sein
sollten, leer sein. Es kann w?hrend der Arbeit die Verbindung zur Datenbank
unterbrochen werden. Besser ist da eine ordentliche Fehlerbehandlung in
allen Schritten des Zugriffes mit einer entsprechenden Information an den
bediener.


--
Viele Gruesse

Peter

16-Feb-10 12:47 AM

Hallo,



Nein. Es kann auch sein, dass nur in einer bestimmten Tabelle bestimmte DS
korrupt sind, weil gerade die eine Memory-Page betroffen ist.

Gruss - Peter

16-Feb-10 02:47 AM

Hallo Susann,


Nein, davon kann man nicht ausgehen.
Weder ein fehlerfreies Öffnen der Connection zur DB
noch ein Zugriff auf ein bestimmtes oder auch mehrere
Felder sind eine Garantie dafür, dass der Rest der
DB auch fehlerfrei gelesen und/oder bearbeitet werden
kann.

Eine solche Prüfung beim Programmstart wäre auch
wenig sinnvoll, da es viele Möglichkeiten gibt, dass
eine DB erst während des eigenen Programmlaufes
beschädigt wird oder anderweitig nicht mehr zugänglich
ist.

Eine saubere und sinnvolle Lösung kann also nur
eine lückenlose Fehlerüberwachung für alle DB-Zugriffe
während der gesamten Programmlaufzeit sein.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

16-Feb-10 03:21 AM

Hallo nochmal,

ausgehend vom Ursprungsposting gehe ich von einer
*.mdb aus.
Hier wäre es z.B. sinnvoll, beim Programmstart zu
prüfen, ob in der (evtl. vom Benutzer selbst) ausgewählten
*.mdb die für den Programmablauf erforderlichen Tabellen
mit den erforderlichen Feldern vorhanden sind.
Wenn "ja", normaler Programmstart, wenn "nein",
entsprechende Meldung ausgeben und Programm
beenden.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)