dbMaxBufferSize und Dateischrott :-(

08/05/2009 - 09:45 von Wolfgang Schwarz | Report spam
Hallo Forum,

Ich habe eine VB6/DAO 3.51-Anwendung welche eine Datenbank-Datei zerstört.
(VB-IDE oder EXE stürzt ab oder es kommt DAO-Fehlermeldung 3159, 3343 etc.
und die Datei ist korrupt)
Alles für mich ohne Sinn !
Mit welchem Befehl kann man denn eine Datei "schrotten", so einen gibt es
doch garnicht.
Erst nach einem Compact-Database kann mit der Datei wieder gearbeitet
werden.

Das kurisose ist nur das diese Anwendung (Mehrfirmen-Fàhig) bei 29 Firmen
làuft und bei der 30. nicht !
Dabei kann ich an den Daten nichts außergewöhnliches feststellen (sind halt
immer andere Adress-/Rechnung-Daten).
Das Problem mit der 30.Firma tritt auch auf verschieden Rechner auf,
allerdings in unterschiedlichen Situationen - mal bereits nach 4 Rechnung,
mal erst nach 100 Rechnungen.

Nach vielen Tests habe ich nun mal beim Start der Anwendung eingebaut:

DBEngine.setoption dbMaxBufferSize,4096

Und es làuft !

Aber:

DBEngine.SetOption dbMaxBufferSize,128000

làuft es auch.

Bisher habe ich mit der MaxBufferSize nichts gemacht, lt. Doku wird
Buffer-Größe anhand des verfügbaren Arbeitsspeichers automatisch verwaltet.
Und hier habe ich nun den Verdacht das dabei ein Fehler in DAO vorhanden
ist, und dieser Speicher begrenzt werden muss. Wenn das Beispiel von
dbMaxBufferSize von einem Rechner mit 64MB Arbeitspeicher ausgeht, dann ist
dieses angesichts heutiger Giga-Byte-RAM-Größen schon sehr alt.
(http://support.microsoft.com/kb/187872)

Mein Problem ist nun das ich nicht weis ob ich das Problem gelöst habe, oder
aber den Fehler nur "vor mir herschiebe"

Nach welchen Kritieren ist den die Größe von dbMaxBufferSize festzulegen ?
Ich finde nur hunderte von Hinweisen wie DAO diese Größe automatisch
berechnet, nicht aber warum ich diese Größe manuell setzen soll, und wie
groß !

Hat jemand Erfahrung dbMaxBufferSize, und könnte diese hier
freundlicherweise kundtun ?

Vielen Dank für allen Antworten

Wolfgang Schwarz
 

Lesen sie die antworten

#1 Peter Götz
08/05/2009 - 11:37 | Warnen spam
Hallo Wolfgang,

Ich habe eine VB6/DAO 3.51-Anwendung



Wenigstens DAO 3.6 sollte es inzwischen aber schon sein.

Welche Version der Jet-Engine ist auf dem fraglichen
Rechner installiert?
Welches Betriebssystem?

welche eine Datenbank-Datei zerstört.
(VB-IDE oder EXE stürzt ab oder es kommt DAO-Fehlermeldung
3159,



Der Fehler 3159 sagt, dass versucht wurde via RS.Bookmark
auf eine in der Bookmarksauflistung nicht vorhandene Bookmark
zu positionieren.

3343 etc. und die Datei ist korrupt)



Der 3343 deutet auf eine beschàdigte *.mdb hin.

Alles für mich ohne Sinn !
Mit welchem Befehl kann man denn eine Datei "schrotten",
so einen gibt es doch garnicht.



Mit jedem Schreibzugriff auf eine *.mdb kann man das,
wenn man das Caching der Jet-Engine nicht entsprechend
behandelt.

Erst nach einem Compact-Database kann mit der
Datei wieder gearbeitet werden.



In vereinzelten Fàllen kann sogar ein Compact-Database
die *.mdb nicht mehr reparieren.

Das kurisose ist nur das diese Anwendung (Mehrfirmen-Fàhig)
bei 29 Firmen làuft und bei der 30. nicht !



Das dürfte wohl eher reiner Zufall sein.
Kommt halt darauf an, welche Konkurrenzbedingungen
beim Mehrbenutzerbetrieb gerade auftreten.

Dabei kann ich an den Daten nichts außergewöhnliches
feststellen (sind halt immer andere Adress-/Rechnung-Daten).



Mit den Daten hat das eher nichts zu tun,
sondern wie schon erwàhnt mit dem Caching
der Jet-Engine, welches von Deiner Anwendung
vermutlich nicht oder nicht richtig behandelt wird.

Das Problem mit der 30.Firma tritt auch auf verschieden
Rechner auf, allerdings in unterschiedlichen Situationen -
mal bereits nach 4 Rechnung, mal erst nach 100 Rechnungen.



Ein weiterer Hinweis auf nicht oder falsch behandeltes
Caching der Jet-Engine.

Schau Dir mal die folgenden Artikel an

http://support.microsoft.com/kb/303519

http://support.microsoft.com/kb/200300

Was im zweiten Artikel zu JRO.RefreshCache steht
gilt bei DAO für DBEngine.Idle RefreshCache.

Und dann schau Dir auch mal die OH zu DBEngine.Idle an.

Mit

DBEngine.Idle dbRefreshCache

kann man die Jet-Engine zwingen, noch im Datenpuffer
(Cache) befindliche Daten sofort in die phys. *.mdb
wegzuschreiben. Nach schreibenden Zugriffen im
Mehrbenutzerbetrieb also

DBEngine.Idle dbRefreshCache

ausführen um so den Datenpuffer sofort wegzuschreiben.
Den gleichen Effekt, sofortiges Wegschreiben und
aktualisieren des Datenpuffers erreicht man auch, wenn
man die jeweiligen DB-Zugriffe in eine Transaktion packt.
Mit dem Commit wird dann auch der Datenpuffer sofort
weggeschrieben.

Ohne DBEngine.Idle dbRefreshCache und/oder Transaktion
kann es mehrere Sekunden dauern bis neue, geànderte oder
zu löschende Daten in der phys. DB aktualisiert werden.
Beim Mehrbenutzerbetrieb kann es dann zu Überschneidungen
und zum Beschàdigen der *.mdb kommen.

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

Ähnliche fragen