Probleme beim komprimieren einer Access Datenbank
-
Hallo zusammen
Ich habe ein Problem bei der Benutzung einer Access Datenbank: Da auch regelmässig Datensätze gelöscht werden sollen, muss die Datenbank hin und wieder komprimiert werden. Ich versuchte nun, die Datenbank mit
CDaoWorkspace::CompactDatabase(source, dest, dbLangGeneral, 0);
zu komprimieren, was auch gelingt. Beim beenden meiner Applikation bekomme ich dann aber immer eine Debug Assertion wie folgt: appcore.cpp, Line 672. Leider gibt mir auch die Aufrufliste nicht vor, wo denn der Aufruf war. Der letzte Aufruf kam aus der DllMain.
Mache ich was bei dem Komprimierungsaufruf falsch? Ich versuchte, den Aufruf zu Beginn (also vor dem öffnen der DB), am Ende (nach dem schliessen der DB) und während des laufenden Programms durchzuführen. Immer mit dem gleichen Ergebnis.
Ausserdem ist diese Art anscheinend deprecated, gibt es da etwas neueres? Ich habe in der MSDN gesucht, aber bisher nichts gefunden.
Vielen Dank für eure Hilfe!
-
hm hab ich zwar noch nie gemacht, aber da hier niemand anders eine Idee hat, würde ich vorschalgen, dass du mal schaust ob du irgendwelche Instanzen hast die zwingend geschlossen werden müssen, bzw. ob du noch in ner Transaktion steckst wenn du schließen willst.
Mal nur so ne Vermutung
-
Plotter schrieb:
Ich habe ein Problem bei der Benutzung einer Access Datenbank: Da auch regelmässig Datensätze gelöscht werden sollen, muss die Datenbank hin und wieder komprimiert werden.
das ist gar nicht der fall. natürlich wird der freispeicher wiederverwendet. laß die datenbank mal in ruhe, sie wird sich ne zeit lang ausdehnen, immer langsamer, und dann stagnieren.
was du mit dem dauernden komremieren anrichtest, ist nur das herbeiwünschen eines bitfehlers. und zeitverschwendung. das packen braucht natürlich zeit, aber auch das wachsen-lassen bei der benutzung.Ich versuchte nun, die Datenbank mit
CDaoWorkspace::CompactDatabase(source, dest, dbLangGeneral, 0);
zu komprimieren, was auch gelingt.
ich hab auch mal automatisch komprimiert (als vorstufe des automatischen backups). mit starten von access.exe mit befehlszeilenschalter /COMPACT oder so ging das auch. ohne fehler. vielleicht geht's bei dir ja auch so besser.
-
Hallo Leute
Danke für eure Antworten.
@Polofreak
Ich habe auch versucht, die Komprimierung beim Start der Applikation durchzuführen, noch bevor überhaupt die Datanbank geöffnet wird. Und auch dort habe ich diesen Fehler bekommen.@Volkard
Die Methode mit dem Schalter /COMPACT kann ich nicht einplanen, weil unsere Rechner ohne Office rausgehen. Der Kunde müsste das selbst machen, und das kann ich nicht verlangen.
Soweit ich weiss, wird bei Access der Speicher nicht wirklich gelöscht, sondern nur als gelöscht markiert. Erst durch das komprimieren wird der Speicher endgültig verworfen.Von der Microsoft- Homepage:
Wenn Sie Daten oder Objekte in einer Access-Datenbank löschen, oder wenn Sie Objekte in einem Access-Projekt löschen, kann dies zur Fragmentierung der Datei und zu einer ineffizienten Speicherplatznutzung führen. Durch das Komprimieren der Access-Datei wird eine Kopie der Datei erstellt und die Art der Speicherung der Datei auf dem Datenträger neu geordnet.Wie soll denn das funktionieren, dass es plötzlich nicht mehr Speicher braucht? Ich wünschte, du hast recht, aber bisher habe ich nur gegenteiliges gelesen. Und meine bisherigen Beobachtungen decken sich damit.
-
der speicher wird nur als gelöscht markiert. und wenn wieder speicher gebraucht wird, wird zuerst der gelöschte speicher benutzt. wenn kein gelöschter speicher mehr da ist, dann ersat muss die datenbankdatei auf der platte wachsen.
mal angenommen, deine datenbank hat über den zeitverlauf wechselnd so zwischen 100k und 200k nutzdaten. dann wächst sie natürlich, bis sie 200k erreicht hat. aber dann gibt's keinen grund mehr, weiterzuwachsen.
es wird aber noch mehr speicher gebraucht. es gibt afair auch abfragen, die speicher in der datenbankdatei fressen (und natürlich beim ende wieder als gelöscht markieren, der speicher ist dann nicht weg).
probiere es doch mal aus, ich sage dir mal voraus, daß sie die ersten tage viel wächst, nach ner woche kaum noch und nach nem monat siehste es nicht mehr. dabei gehe ich davon aus, daß du inerhalb der datenbank nicht kompletten unfug programmiert hast.unter unfug verstehe ich ne abfrage, die in einer nach zeit sortieren liste von buchungen mit sagen wie mal 5000 buchungen pro semester eine abfrage machst, die nachfolger- und vorgängerbuchung herausfindet, indem du in beide richtungen die tabelle mit sich selbst kreuzt und das maximum der kleineren bzw minimum der größeren selektierst. die zwischentabelle mit 125 millarden buchungstripeln könnte der datenbank weh tun, eventuell. und ich spreche da aus erfahrung. *g*
-
Ich habe die Erfahrung gemacht, dass es auf jeden Fall besser ist, die DB gelegentlich zu komprimieren. Dazu benutze ich die Methode CompactDatabase der JetEngine. Probleme hatte ich damit bisher noch nicht.
Beispiel:
[code] IJetEnginePtr pJet(__uuidof(JetEngine)); pJet->CompactDatabase( "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + _bstr_t(DBPath), "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + _bstr_t(DBPath) + "new"); [/code]
Natürlich darf die DLL nicht fehlen
#import "C:\Programme\Gemeinsame Dateien\System\Ado\MSJRO.DLL" no_namespace
Hoffentlich hilft dir das.
P.S. Der Aufruf geschieht immer bei geschlossener DB.
-
öhm ich hab mich oft bei Problemen irgendwie damit abgefunden weil es halt nun mal MS ist.
Ich kenne dein Problem nun leider nicht aber ich habe das schon bei Powerpoint beobachtet wenn man da oft Bilder rein packt und wieder löscht dann wird die Datei immer größer! Dort gehe ich einfach hin und mach speichern unter und dann einen neuen namen und schon gibt er den Speicher wieder frei.
Vielleicht hilft das dir ja weiter wenn du ein Kopie speicherst und die dann über die alte kopierst oder ähnliches
-
Das Problem mit der immer grösser werdenden Datei hast du nicht nur beim Powerpoint, sondern auch bei Word. MS speichert da weiss der Teufel was alles rein. Z.B wäre es möglich, die Datei wieder Schritt für Schritt zurücksetzen, wenn du das Format entsprechen entschlüsseln könntest. Da ist also viel mehr drin als die paar Buchstaben, Bilder und Formatierungen.
Aber zurück zum Thema: Wie gesagt habe ich bisher mit Access andere Erfahrungen gemacht, wobei ich auch zugeben muss, dass ich bei meiner Web-Applikation die Datenbank regelmässig mal komprimiere. Ich müsste mal meine jetzige Datenbank ne Weile beobachten, um zu sehen, ob Volkard recht hat. Und sonst schaue ich das mit der JetEngine gerne mal an. Aber auf ein Feedback müsst ihr noch etwas warten.
-
@orroz
Hoffentlich guckst du wieder mal rein, hab mal versucht, deine Methode auszuprobieren. Wenn ich aber die MSJRO.DLL importiere, kriege ich eine ganze Menge Fehler:
msjro.tlh(198) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'ConflictTables' msjro.tlh(198) : error C2501: 'JRO::IReplica::_RecordsetPtr': Fehlende Speicherklasse oder Typspezifizierer msjro.tlh(198) : error C2501: 'JRO::IReplica::ConflictTables': Fehlende Speicherklasse oder Typspezifizierer msjro.tlh(226) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'GetConflictTables' msjro.tlh(226) : error C2501: 'JRO::IReplica::_RecordsetPtr': Fehlende Speicherklasse oder Typspezifizierer msjro.tlh(226) : warning C4183: 'GetConflictTables': Rückgabetyp fehlt; Memberfunktion, die 'int' zurückgibt wird angenommen error C2143: Syntaxfehler: Es fehlt ';' vor 'JRO::IReplica::GetConflictTables' msjro.tli(111) : error C2433: '_RecordsetPtr': 'inline' bei der Deklaration von Daten nicht zulässig msjro.tli(111) : error C2501: '_RecordsetPtr': Fehlende Speicherklasse oder Typspezifizierer msjro.tli(115) : error C2064: Ausdruck ergibt keine Funktion, die 2 Argumente übernimmt
Muss ich sonst noch auf etwas achten? Hab im Google noch was über die Datei Msado26.tlb gefunden, die meist im gleichen Zusammenhang erwähnt wurde, z.B. hier: http://www.codeguru.com/Cpp/data/mfc_database/microsoftaccess/article.php/c4327 . Aber auch dieses Beispiel bringt mich nicht weiter. Hast du noch einen Tipp für mich?
Vielen Dank!