Datenbank voll - lässt sich nicht mehr ändern

[jorgaeff]

Jetzt muss ich mich doch mal an den Support wenden. Habe folgendes Problem:

Die Datenbank ist voll und ich kann das nicht mehr ändern (habe Baywotch V3.0 Standard - bin vor kurzem umgestiegen).

Habe bereits folgendes versucht:
- Datenbank komprimieren/reparieren (ich bekomme eine Meldung, dass erfolgreich komprimiert werden konnte - an der Größe ändert sich jedoch nichts)
- Artikelbeschreibungen in Text umwandeln (bekomme Laufzeitfehler -> es wird nichts umgewandelt)
- Artikelbeschreibungen löschen (bekomme Laufzeitfehler -> es wird nichts gelöscht (habe 24 Std. gewartet und dann abgebrochen))
- Artikel unter "gelöschte Objekte" endgültig löschen (bekomme ebenfalls Laufzeitfehler -> kann keine Artikel löschen)

Und hier die Fehlermeldung:
Unerwarteter Laufzeitfehler:
Modul: s_ClearCBtempFlag
Zeile: 0
Code: -2147467259
Description: ungültiges Argument
Source: Microsoft JET Database Engine
Datenbank: c:\programme\baywotch3.1\baywotch.db4 (2,00 GB)
LastDLLError: 0
Zeit: egal
App Version: 3.1.27 FINAL.2
DAO Version: 3.6
ADO Version: 2.8
Winsock Version: 6.1.97.82

Schon mal danke für jegliche Hilfe.

jorgaeff

[denkmann]

Hallo jorgaeff,
erst einmal herzlich Willkommen im Forum!

Die Datenbank ist voll und ich kann das nicht mehr ändern (habe Baywotch V3.0 Standard - bin vor kurzem umgestiegen).

Es tut mir leid, daß Du Schwierigkeiten mit der Datenbank hast. Die von Dir genannten Möglichkeiten sollten eigentlich im Normalfall funktionieren und helfen, die Datenbankgröße zu reduzieren.

Daß in Deinem Fall Fehler gemeldet werden liegt wohl daran, daß die Datenbank die kritische Größe von 2GB erreicht hat. Ab einem bestimmten Schwellenwert wehrt sich die Datenbank gegen jegliche Form von Schreibzugriffen.

Wichtig für mich wäre zu wissen, wie es dazu überhaupt kommen konnte. BayWotch ist mit zahlreichen Mechanismen ausgestattet, die genau dieses Problem verhindern sollen.

So wird beispielsweise eine Warnmeldung ausgegeben, sobald die Datenbank 50% ihrer maximalen Kapazität erreicht. Weitere Warnungen folgen dann bei jeweils 10% Vergrößerung.

Weiterhin sollte die Datenbank ab der Größe von 2.136.997.887 Bytes (das sind ca. 10MB vor der kritischen 2GB Grenze) keinerlei Schreibzugriffe mehr erlauben. Es wird dann eine entsprechende Meldung mit den möglichen Schritten zur Verkleinerung ausgegeben.

Ist das alles bei Dir nicht passiert?

Hast Du eventuell noch eine Datensicherung? BayWotch legt beim Komprimieren automatisch eine Sicherung mit dem Namen baywotch.db4.bak an.

Ich kann Dir nur anbieten, daß Du die Datenbankdatei auf eine DVD brennst und mir zuzusendest. Ich versuche dann, ob ich die Daten mit direktem Zugriff unter Access retten kann.

[jorgaeff]

Hallo Elmar,

erst einmal vielen Dank für die ultra schnelle und umfassende Rückantwort.

Kann mich nicht daran erinnern, dass ich Meldungen bezüglich der Datenbank erhalten habe. Wäre mir bestimmt aufgefallen, da ich diese Meldungen von der Arbeit her kenne (hab aber ansonsten keine Ahnung von Datenbanken).

Zum Glück habe ich noch die "alte Datenbank" von Baywotch II. Die ist ungefähr einen Monat alt. Dann fehlen mir halt die letzten vier Wochen, aber lebensnotwendig ist das nicht. Aber trotzdem danke für das Angebot mit der DVD.

Hatte zuerst die Beta-Version von Baywotch III installiert und seit Erscheinen der Final diese zusätzlich aufgespielt. Die Datenbank habe ich von der Beta in die Final verschoben. Vielleicht liegt hier die Ursache?

Danke für die Hilfe,

jorgaeff

[denkmann]

Hallo jorgaeff,

Hatte zuerst die Beta-Version von Baywotch III installiert und seit Erscheinen der Final diese zusätzlich aufgespielt. Die Datenbank habe ich von der Beta in die Final verschoben. Vielleicht liegt hier die Ursache?

kommt darauf an, wie groß die 2'er DB war. Wenn diese ebenfalls annähernd 2GB groß war (ich weiss ja nicht, wieviele Artikel Du in 4 Wochen einliest), erklärt das natürlich die fehlenden Warnmeldungen; wobei zumindest eine hätte erscheinen müssen! Aber das kann ich nochmal prüfen. Wäre sicher nicht verkehrt, wenn nach dem Import ebenfalls eine entsprechende Warnung ausgegeben würde.

Das erklärt allerdings nicht, warum BayWotch 3.1 nicht bei 10MB vor Limit den Hahn dicht gemacht hat.

[jorgaeff]

Genau das wundert mich auch. Die alte Datenbank war gerade 1 GB groß und da hab ich die Daten über Monate hinweg eingelesen. Kann mir nicht vorstellen, dass die neue in 4 Wochen so anschwillt.
Ach ja, die Meldung zum Erreichen des Datenbanklimits kann man in den Optionen deaktivieren. Bei mir war sie definitiv aktiviert.

Was mich auch wundert, dass in der linken Spalte (wo die Datenbank/Ignorieren und gelöschte Objekte drinsteht) 2x import aus db3 drinsteht, so als ob die Daten 2x in die Datenbank importiert worden wären und jetzt doppelt drinstehen. Ist das normal?

[denkmann]

Hallo jorgaeff,

Genau das wundert mich auch. Die alte Datenbank war gerade 1 GB groß und da hab ich die Daten über Monate hinweg eingelesen. Kann mir nicht vorstellen, dass die neue in 4 Wochen so anschwillt.

Du wirst ja, wenn ich Dich richtig verstanden habe, nun die 2'er Datenbank erneut importieren. Es wäre toll, wenn Du dann einmal gezielt darauf achten könntest, was da genau abläuft.

Ich werde aber parallel versuchen, das ganze mal mit einem "gestellten" Import nachzuspielen.

Was mich auch wundert, dass in der linken Spalte (wo die Datenbank/Ignorieren und gelöschte Objekte drinsteht) 2x import aus db3 drinsteht, so als ob die Daten 2x in die Datenbank importiert worden wären und jetzt doppelt drinstehen. Ist das normal?

Dann wurde zwei mal der Import ausgeführt. Das ist aber nicht sonderlich schlimm, denn bereits bestehende Artikel können nicht mehrfach gespeichert werden. Es wurde also dann lediglich der Import-Ordner erneut angelegt.

[denkmann]

Hallo jorgaeff,

ich habe das mal nachgespielt... mit einer 2'er Datenbank >1GB, die ich importiert habe.

BayWotch hat wie erwartet unmittelbar nach der nächsten Onlineübertragung (Onlinesuche oder Abgleich) eine Warnung im Ereignisprotokoll ausgegeben. Das sieht dann z.B. so aus:



Diese Meldung wird dann wiederholt, sobald die Datenbankgröße um 10% zunimmt.

Ab 99% erscheint die Warnung dann nach jeder Onlineaktion.

[benu]

Hallo,
in diesem Zusammenhang (naja nicht direkt) fällt mir noch etwas ein.

Als ich mal wieder suchen wollte, habe ich versehentlich weder einen
Verkäufer noch einen Suchtext eingegeben.
Daraufhin wurde die gesamte DB nach dem nicht vorhandem Suchwort / Verkäufer gesucht.
Nach einer Zigarette und ner 1/2 Kanne Kaffee war die Suche dann auch beendet.

Der Punkt war,
nachdem Baywotch wieder ansprechbar war, hatte ich keine Lust
noch etwas zu machen und beendete Baywotch.

Bei dem nächsten Neustart hat Baywotch mir die Freundschaft gekündigt
und seuselte etwas von erstmal die Datenbank komprimieren,
dann sehen wir weiter

Die DB war dann auch >2GB,
vor dieser Aktion mit dem suchen war die DB so um die 1,4GB groß.

Ich denke da könnte noch eine Prüfung erfolgen ob mindestens
eines dieser Felder einen Text enthält.

[denkmann]

Hi benu,

Die DB war dann auch >2GB,
vor dieser Aktion mit dem suchen war die DB so um die 1,4GB groß.

ein guter Beitrag! Ja, bei einer Datenbanksuche wird das search_result Flag verändert. Ich werde mal überprüfen, in wie weit es dabei tatsächlich zu dieser enormen Datenbankvergrößerung kommt.

Ich denke da könnte noch eine Prüfung erfolgen ob mindestens
eines dieser Felder einen Text enthält.

Naja, grundsätzlich auf diese beiden Felder zu prüfen wäre ungünstig. Es kann ja durchaus sein, daß der User eine Suche nach allen Artikeln starten möchte, oder nach allen mit einem bestimmten Flag.

[jorgaeff]

So, hab jetzt die volle Datenbank gekillt und die alte aus Baywotch II importiert. Soweit alles in Ordnung - hab auch gleich brav die Meldung bekommen, dass die DB zu 53% voll ist.

Werd das jetzt mal genauer verfolgen. Melde mich wieder wenn was außergewöhnliches passiert.

[Mischa]

ein guter Beitrag! Ja, bei einer Datenbanksuche wird das search_result Flag verändert. Ich werde mal überprüfen, in wie weit es dabei tatsächlich zu dieser enormen Datenbankvergrößerung kommt.

ich hatte ja mal angeregt, dieses search-flag nicht direkt in die tabelle tblAuction zu schreiben, sondern in eine eigene tabelle, die dann nur einen autozähler (id) und die auctionsnummer enthält.

bei access kann eine änderung von bestehenden daten sehr datenbanklastig sein: da vorher meist geprüft wird, ob die daten von einem anderen nutzer geändert werden, daher werden meist alle datenfelder in der datenbank mit den aktuellen daten in der tabelle verglichen, und wenn keine änderungen durchgeführt wurden erst aktualisiert. zumindest erfolgt dies bei Access-formularen beim zugriff auf eine SQL-Datenbank (kann man schön mit den datenbankanalyseprogrammen sich anschauen). inwieweit dies auch von VB gemacht wird weiß ich nicht.

wenn man dann noch für jede ausgeführe suche eine such_id speichert, dann kann man auch auf bisher durchgeführte suchen schnell zurückgreifen über die such_id ohne die suche direkt noch mal durchführen zu müssen, da dann über such_id und auction_id die daten schnell abgefragt werden können.

auch entfällt bei der implementierung einer search_id die notwendigkeit, das search-flag erst wieder zurücksetzen zu müssen, da einfach die search_id weitergezählt wird für eine neue suche.

eine auslagerung dieser tabelle in eine extra temp-datenbank läßt dann die hauptdatenbank unberührt.

die tempdatenbank für tblSearch kann dann beim beenden von BW oder auf anforderung einfach gelöscht werden und wird beim neustart von BW einfach wieder neu erstellt.

Vorteil:
- keine änderung der eigentlichen datensätze
- schnelle durchführung der suche, da keine datensätze geändert werden müssen, sondern nur datensätze (auticon_id) in eine neue tabelle angefügt werden
- zugriff auf vorherige suchen (kleine suchhistorie möglich)
-

tabellen aufbau:

externe eingebunde tabelle "tblSearch":

id: autoincrement
search_id: integer
auction_id: integer

index über:
search_id und auction_id

[Boomer]

Hallo,

ich habe jetzt ein ähnliches Problem. Die Datenbank bleibt bei allen Löschversuchen beharrlich auf 122390 Artikeln und 1,99 GB. Ich dachte bisher immer ich hätte evtl. zu wenig gelöscht. Aber heute habe ich mal über 20.000 Artikel auf einen Schlag gelöscht. Keine Reaktion außer der Meldung über die erfolgreiche Komprimierung.

Mir ist vorher die Anpassung der Datenbankstruktur auf die neue Version (*.52) abgebrochen worden - könnte es auch daran liegen?

Gibt es inzwischen eine schnellere Lösung, als die Datenbank einzuschicken?

Gruß Boomer

[denkmann]

Hallo Boomer,

ich habe jetzt ein ähnliches Problem. Die Datenbank bleibt bei allen Löschversuchen beharrlich auf 122390 Artikeln und 1,99 GB. Ich dachte bisher immer ich hätte evtl. zu wenig gelöscht. Aber heute habe ich mal über 20.000 Artikel auf einen Schlag gelöscht. Keine Reaktion außer der Meldung über die erfolgreiche Komprimierung.

bitte beachte, daß es nicht ausreicht, die Artikel zu löschen. Du mußt außerdem den Ordner "Gelöschte Objekte" leeren! Dann sollte die Komprimierung auch eine Verkleinerung der Datenbankdatei bewirken.

Mir ist vorher die Anpassung der Datenbankstruktur auf die neue Version (*.52) abgebrochen worden - könnte es auch daran liegen?

Das kann ich leider schlecht aus der Ferne beurteilen. Dazu müßte ich schon die Datenbank vor mir haben.

Gibt es inzwischen eine schnellere Lösung, als die Datenbank einzuschicken?

Wenn Du MS Access zur Verfügung hast, könnte man mit der Professional Edition direkt an die Datenbank, um zu schauen, ob sich Datensätze manuell löschen lassen. Bei Bedarf nimm bitte per E-Mail Kontakt mit mir auf.

[Boomer]

Hallo Elmar.

oh wie peinlich. 40.000 Artikel waren in "Gelöschte Objekte".
Jetzt ist die DB nur noch etwas mehr, als 1 gig groß.

Jetzt noch kurz eine Frage, ob ich mit dieser Version meiner Datenbank Deiner Meinung nach weiterarbeiten kann:

Ich hatte nach Update von Baywotch, vor dem Update der Datenbankstruktur eine Meldung bekommen, dass die DB 10% größer werden kann und ich im Falle eines Abbruches die zuvor gesicherte Datenbank erst mit der Vorgängerversion verkleinern muss. Abgebrochen ist das ja nun aus bekannten Gründen. Trotzdem scheint alles zu laufen oder wurde meine DB jetzt noch garnicht upgedatet?
Der einzige Punkt, der mir aufgefallen ist, ist dass nach der Komprimierung zunächst die Unterordner der Ordner weg waren. Dann habe ich einmal die .bak umbenannt und geöffnet, danach wieder meine komprimierte DB und die Ordner waren wieder da.

Gruß und Danke für den super Support,

Gruß Boomer

[denkmann]

Hi Boomer,

oh wie peinlich. 40.000 Artikel waren in "Gelöschte Objekte".
Jetzt ist die DB nur noch etwas mehr, als 1 gig groß.

prima, das freut mich!

Ich hatte nach Update von Baywotch, vor dem Update der Datenbankstruktur eine Meldung bekommen, dass die DB 10% größer werden kann und ich im Falle eines Abbruches die zuvor gesicherte Datenbank erst mit der Vorgängerversion verkleinern muss. Abgebrochen ist das ja nun aus bekannten Gründen. Trotzdem scheint alles zu laufen oder wurde meine DB jetzt noch garnicht upgedatet?
Der einzige Punkt, der mir aufgefallen ist, ist dass nach der Komprimierung zunächst die Unterordner der Ordner weg waren. Dann habe ich einmal die .bak umbenannt und geöffnet, danach wieder meine komprimierte DB und die Ordner waren wieder da.

Wie bereits gesagt kann ich nur schwer per Ferne erkennen, ob mit Deiner DB alles i.O. ist.

Wenn allerdings BayWotch ohne Warn- bzw. Fehlermeldung läuft, dann ist die DB zu 99,9% unbeschädigt. Es würde Fehlermeldungen hageln, wenn bei der Datenbankanpassung auch nur ein Feld nicht angepaßt worden wäre.

Eine Datenbankkomprimierung/-Reparatur schafft dann schließlich die restlichen 0,1% Bedenken aus der Welt.