FileDateTime-Vergleich / Routine aus Handbuch für Datenbanksicherung, Fehlverhalten
Verfasst: Di 18. Jun 2024, 21:15
Moin die Runde,
aus dem Handbuch von Robert verwende ich die Routine für die automatische Datenbanksicherung, bei jedem Programmstart. Das funktioniert auch prima - bis die inMax-Vorgabe (Maximale Anzahl der Sicherungen, bevor die älteste überschrieben wird) erreicht ist. Dann aber wurde zeitweilig nicht die älteste überschrieben, sondern immer gleiche, die mit der höchsten Nummer.
Als Ursache habe ich folgendes herausgefunden:
Das Alter der Versionen wird wie in der Handbuch-Routine wie folgt verglichen
(Achtung bei Copy und Paste: URL-Komposition bei mir etwas anders als im Handbuch):
FileDateTime liefert aber das Datum als String im Format "dd.mm.yyyy hh:mmss".
Daher werden die Daten als String verglichen.
- Das Ergebnis ist richtig, wenn z.B. "03.06.2024 17:45:49" mit "03.06.2024 17:46:21" verglichen wird: Das erste, ältere Datum wird als kleiner bewertet.
- Das Ergebnis wird aber falsch, wenn z.B. "20.5.2024 18:07:17" mit "03.06.2024 17:45:49" verglichen wird: Das erste Datum wird als größer bewertet, obwohl es das ältere ist.
Erst wenn man dafür sorgt, dass der Vergleich zwischen "Date"-Formaten vollzogen wird, klappt es wie gewünscht:
Jetzt wird auch der zweite Datumsvergleich aus obigem Beispiel richtig.
Noch 'ne Kleinigkeit:
Außerdem habe ich in der Zeile, die beim ersten Durchlauf überprüft, ob es noch "freie Nummern" gibt:
noch ein
angefügt. Damit wird gesichert, dass auch dann nicht über den zugelassenen Nummernraum hinausgeschossen wird,
wenn es Dateiversionen mit inMax+1 (und weitere) als Nummer gibt, z.B. weil zuvor mal eine größere Zahl zugelassen war.
Tschüs,
Knut
aus dem Handbuch von Robert verwende ich die Routine für die automatische Datenbanksicherung, bei jedem Programmstart. Das funktioniert auch prima - bis die inMax-Vorgabe (Maximale Anzahl der Sicherungen, bevor die älteste überschrieben wird) erreicht ist. Dann aber wurde zeitweilig nicht die älteste überschrieben, sondern immer gleiche, die mit der höchsten Nummer.
Als Ursache habe ich folgendes herausgefunden:
Das Alter der Versionen wird wie in der Handbuch-Routine wie folgt verglichen
(Achtung bei Copy und Paste: URL-Komposition bei mir etwas anders als im Handbuch):
Code: Alles auswählen
If FileDateTime(LEFT(sUrl_Start,LEN(sUrl_Start) - 4,0) & "_" & k & ".odb") _
<=FileDateTime(LEFT(sUrl_Start,LEN(sUrl_Start) - 4,0) & "_" & k+1 & ".odb") Then
[...]
Daher werden die Daten als String verglichen.
- Das Ergebnis ist richtig, wenn z.B. "03.06.2024 17:45:49" mit "03.06.2024 17:46:21" verglichen wird: Das erste, ältere Datum wird als kleiner bewertet.
- Das Ergebnis wird aber falsch, wenn z.B. "20.5.2024 18:07:17" mit "03.06.2024 17:45:49" verglichen wird: Das erste Datum wird als größer bewertet, obwohl es das ältere ist.
Erst wenn man dafür sorgt, dass der Vergleich zwischen "Date"-Formaten vollzogen wird, klappt es wie gewünscht:
Code: Alles auswählen
DIM Datetime_k0 AS DATE
DIM Datetime_k1 AS DATE
[...]
FOR k = inMax - 1 TO 1 STEP -1
DateTime_k0=FileDateTime(LEFT(sUrl_Start,LEN(sUrl_Start) - 4,0) & "_" & k & ".odb")
DateTime_k1=FileDateTime(LEFT(sUrl_Start,LEN(sUrl_Start) - 4,0) & "_" & k+1 & ".odb")
IF Datetime_k0 <= Datetime_k1 THEN
[...]
Noch 'ne Kleinigkeit:
Außerdem habe ich in der Zeile, die beim ersten Durchlauf überprüft, ob es noch "freie Nummern" gibt:
Code: Alles auswählen
IF NOT FileExists(LEFT(sUrl_Start,LEN(sUrl_Start) - 4,0) & "_" & i & ".odb")
Code: Alles auswählen
OR (i>inMax)
wenn es Dateiversionen mit inMax+1 (und weitere) als Nummer gibt, z.B. weil zuvor mal eine größere Zahl zugelassen war.
Tschüs,
Knut