Komprimieren: Fehler bei nicht exclusivem Zugriff

[Mischa]

vermutlich, weil die datenbank noch von einem anderen Tool geöffnet war gab es diesen Fehler:

Code: Alles auswählen

Unerwarteter Laufzeitfehler:

Modul: f_DBCompact
Zeile: 0
Code: 75
Description: Fehler beim Zugriff auf Pfad/Datei
Source: BayWotch
LastDLLError : 0
Zeit: 29.06.2005 21:17:01
App Version: 3.0.30 BETA.32
DAO Version: 3.6
ADO Version: 2.8
Winsock Version: 6.1.97.82

BayWotch hat diese Fehlermeldung zur Vereinfachung der Fehlersuche im BayWotch Programmverzeichnis als Datei mit dem Namen runtime.txt abgelegt.

Klicke [OK], um fortzufahren, oder [ABBRECHEN], um BayWotch zu beenden.

könnte man diesen jedoch nicht etwas besser für den nutzer machen? evtl vorher die exclusive nutzung prüfen und entsprechende Meldung ausgeben ohne einen "richtigen" Fehler auszugeben?

[Mischa]

und noch was:

in der runtime.txt stehen die wichtigsten daten des fehlers.

aber: könnte man in der runtime.txt nicht auch den kompletten wortlaut aus der Fehlermeldungsbox anzeigen? das wäre manchmal auch für einen selbst hilfreich, da man sich nicht alle Fehlermeldungen merken kann.

[denkmann]

Hi Mischa,

in der runtime.txt stehen die wichtigsten daten des fehlers.

aber: könnte man in der runtime.txt nicht auch den kompletten wortlaut aus der Fehlermeldungsbox anzeigen? das wäre manchmal auch für einen selbst hilfreich, da man sich nicht alle Fehlermeldungen merken kann.

ich verstehe nicht, was Du meinst. Die runtime.txt ist ein exaktes Abbild der Fehlermeldungsbox. Was fehlt Dir da?

[Mischa]

ich verstehe nicht, was Du meinst. Die runtime.txt ist ein exaktes Abbild der Fehlermeldungsbox. Was fehlt Dir da?

mhhh ... stimmt ...

dann vermisse ich vermutlich, daß auch die "normalen" (fehler)meldungen ala "Datenbank ist zu groß" etc. als Fehlermeldung abgespeichert werden.

[denkmann]

ich verstehe nicht, was Du meinst. Die runtime.txt ist ein exaktes Abbild der Fehlermeldungsbox. Was fehlt Dir da?

mhhh ... stimmt ...

dann vermisse ich vermutlich, daß auch die "normalen" (fehler)meldungen ala "Datenbank ist zu groß" etc. als Fehlermeldung abgespeichert werden.

Auch das wird gemacht... sobald das Ereignisprotokoll erscheint, wird auch ein Protokoll als Textdatei geschrieben. Der Name ist abhängig von der jeweiligen Aktivität... einfach mal nach *.txt schauen.

[Mischa]

1) abgespeicherte Fehlermeldung


da muß ich dir wiedersprechen:


ich hatte eben beim abgleich die "datenbank ist zu groß" meldung und danach direkt den:

Code: Alles auswählen

Unerwarteter Laufzeitfehler:

Modul: s_ModifyArticleInDB
Zeile: 0
Code: -2147217887 (3617)
Description: Ungültiges Argument.
Source: Microsoft JET Database Engine
LastDLLError : 0
Zeit: 30.06.2005 14:53:39
App Version: 3.0.30 BETA.32
DAO Version: 3.6
ADO Version: 2.8
Winsock Version: 6.1.97.82

BayWotch hat diese Fehlermeldung zur Vereinfachung der Fehlersuche im BayWotch Programmverzeichnis als Datei mit dem Namen runtime.txt abgelegt.

Klicke [OK], um fortzufahren, oder [ABBRECHEN], um BayWotch zu beenden.

aber nur dieser fehler steht in der runtime.txt
die anderen .txt dateien sind nicht mit fehlern von dieser uhrzeit gefüllt.




Automatischer Stop von Abgleich bei Überschreitung einer Maximalgröße der Datenbank

Desweiteren wäre es gut, wenn Baywotch z.B. beim Abgleich die Datenbankgröße vor dem speichern kontrolliert und nicht das programm ins Messer laufen läßt und auf einen "Unerwarteter Laufzeitfehler:" wartet.

Dann wäre es gut, wenn baywotch ab einer bestimmten Größe die Abläufe anhält und die notwendigen offenen Jobs noch erledigt und dann mit diesem Sicherheitspuffer kontrolliert stoppt.

ich hatte einen Abgleich "Alle unvollständigen Artikel" gemacht und der ist dann an diesen Fehler gekommen (durch die Datenbank größe). Nachteil: sinnvollerweise kann man hier nur auf "Abbrechen" klicken und es fehlen jetzt bestimmt die ca. 6-12 bilder, die bei einem Stop normalerweise noch nachgeladen werden müssen.

[denkmann]

Hi Mischa,

die nächste Version wird die Hinweise bzgl. der Datenbankgröße etwas flexibler handhaben. Derzeit kommt eine 50%, 75% und 90% Meldung, und das jeweils nach jedem Programmstart erneut. Das neue Update geht ab 50% in 10%-Schritten aufwärts und speichert dabei die Datenbankgröße, so daß die Meldung wirklich nur einmal kommt.

Der User ist also ausreichend vorgewarnt. Mal schauen, ob sich noch ein "Not-Aus" bei 99% realisieren läßt.

[Mischa]

Der User ist also ausreichend vorgewarnt. Mal schauen, ob sich noch ein "Not-Aus" bei 99% realisieren läßt.

naja ... nur eine warnung nützt nichts, wenn man nicht abschätzen kann wieviel platz denn nun das einlesen der neuen auktionen verschlingt ...

Daher stimme ich voll für ein geregeltes "NOT-AUS".

da ja definitiv bei 2GB schluß ist kann man ja selbst den user festlegen lassen, wieviel puffer er für das not-aus läßt. 1MB - 100MB.

mir ist lieber ich hab noch etwas luft in der DB aber bis dahin ist alles korrekt eingelesen ... anstatt immer den karren vor die wand fahren.



vor allem, weil ich auch mal gelesen habe, daß ein einlesen schon als vollständig gilt, sobald nur einen beschreibung in der tabelle ist. zusätzliche optionen wie bilder oder counter fallen nicht darunter.

wenn nun das Einlesen wegen der DB-Größe hart und mittendrin abbricht, so werden diese optionen später auch nicht eingelesen :-(

[Mischa]

noch ein argument für das geregelte NOT-AUS:


damit kann eine mögliche beschädigung der Datenbank durch den schreibfehler vermieden werden z.b.:

- physische beschädigung der datei
- bzw auch logische beschädigung durch nicht vollständig gespeicherte datenstrukturen