Access - monatlich neue DB erstellen

[stephan3309]

Danke!
So sollte es klappen.

Komme leider von meinem Arbeitsplatz aus nicht auf die Seite des Forums (wird vom
Server als "Chatroom" eingestuft und gesperrt :( )
Deshalb hats mit der Antwort von mir etwas gedauert.

Mit dankbarem Gruß
Stephan

[stephan3309]

Hallo Jürgen,

ich habe noch ein kleines Problem.

Von der Function Neuer_Monat bekomme ich anscheind keinen Wert.
Wenn ich einen Monatswechsel (z.b. durch ändern der systemzeit auf kurz von Monatswechsel) simuliere,
tut sich nichts.

Habe folgendes versucht um den Fehler einzugrenzen:

Delphi-Quellcode:

if Neuer_Monat then Edit1.Color := clred
else
Edit1.Color := clblue;

Eigentlich sollte ja dann beim Übergang vom 31. zum 1. Jeden Monats etwas passieren,
aber das Textfeld wird weder rot noch blau, es bleibt bei der starteigenschaft (grau).

[Jürgen Thomas]

Zitat:

Zitat von stephan3309

Von der Function Neuer_Monat bekomme ich anscheind keinen Wert.
Wenn ich einen Monatswechsel (z.b. durch ändern der systemzeit auf kurz von Monatswechsel) simuliere,
tut sich nichts.

Habe folgendes versucht um den Fehler einzugrenzen:

Delphi-Quellcode:

if Neuer_Monat then Edit1.Color := clred
else
Edit1.Color := clblue;

Eigentlich sollte ja dann beim Übergang vom 31. zum 1. Jeden Monats etwas passieren,
aber das Textfeld wird weder rot noch blau, es bleibt bei der starteigenschaft (grau).

1. Vielleicht fehlt noch Edit1.Refresh;
2. "bekomme ich keinen Wert" kann so nicht stimmen: einen Wert (true oder false) bekommst Du mit Sicherheit; denn eine Exception kann es in dieser Funktion nicht geben.
3. Ich weiß leider nicht, wann/wie ein Delphi-Programm durch 'Now' das Win-Datum erhält (und habe keine Lust, in SysUtils.pas o.ä. und der Win-API zu suchen).
4. Hast Du einmal den Debugger durch diese Funktion laufen lassen und die einzelnen Werte geprüft? Dann müsstest Du doch sehen, was läuft.

Mach doch einmal folgenden Test:

Delphi-Quellcode:

//  gezielt ein Datum übergeben
function TForm1.Neuer_Monat(Vergleich: TDateTime): Boolean;
var Year, Month, Day: Word;
//  Vergleich: TDateTime;
begin
  //  bei dieser Variante könnte man auf die Variable Vergleich verzichten
  //  und DecodeDate(Now...) schreiben; aber zur Vergleichbarkeit lassen wir das
//  Vergleich := Now;
  DecodeDate(Vergleich, Year, Month, Day);
  //  Rückgabe: Day =  1  =>  Neuer_Monat ja
  //  Rückgabe: Day <> 1  =>  Neuer_Monat nein
  Result := Day = 1;
end; 
//  und von einem Hilfsprogramm aus testen nach dem folgenden Motto:
if Neuer_Monat( StrToDateTime('01.01.2000') )
then ShowMessage('true')
else ShowMessage('false');

Viel Erfolg! Jürgen

[stephan3309]

So, jetzt funktionierts, rufe die Funktion jetzt mit einem Timer auf, der einfach 1x die Stunde auf Day = 1 überprüft.

Danke für alle Antworten

Stephan

[Alfalge]

@marabu
besser hätt ichs nicht schreiben können.

Zur Sache:
Ich stimme mit marabu voll überein. Ein schönes Textfile ist doch immer wieder was feines. Die älteren unter uns werden es noch kennen: Textdateien mit fester Satzlänge, Textdateien tabulatorsepariert usw. es gibt ME nichts schnelleres. Satzkennung an den Anfang z.B. die Systemzeit, dann die 15 Werte flat mit festem Offset oder wie auch immer daerein. Und wenn es dann mal ein paar Felder mehr werden, kann man die immer noch anhängen, so ein Satz kann laut String-Definition ja richtig gross werden.

Einen kleinen hätt ich da aber noch. Die Daten sollen 10 Jahre lang nachgehalten werden. Ich vermisse im Denkansatz noch einen Zwischenschritt: Wie sieht es mit der Datensicherheit aus? 500.000 Sätze in einer Access, dbase, paradox oder text Tabelle ist nicht wirklich viel. wenn die Datei aber ständig offen ist, wie soll sie dann zuverlässig gesichert werden?

Mein Vorschlag wäre wirklich Textfile auf Tagesbasis. Dann ist man datentechnisch auf der richtigen Seite:
1. Immer hübsch kleine Dateien, die am folgenden Tag geschlossen sind und nur noch so da stehen (sogenannte soda-Daten).
2. Flatfiles sind in die meisten SQL-Server direkt oder mit wenig Aufwand einzulesen.
3. Flatfiles veralten nicht! Ich bin frei in all meinen Entscheidungen: Lese ich sie in Access ein? Will ich im nächsten Jahr vieleicht ein vielleicht neues Office-Produkt nutzen? Steige ich um auf SQL, auf welches auch immer? Es ist egal, die paar Millionen flachen Sätze hab ich in wenigen Stunden in dem Produkt meiner Wahl. Immer und immer wieder, falls nötig.
4. Siehe 1. Dateien geschlossen und sicherbar. Keine Datenbank kann kaputt gehen, kein Index kann sich zerstören, wenn die Hardware mal Daten spanabhebend verarbeitet, fehlen mir nur die Daten vom Ausfallzeitpunkt bis zu Reparatur. Meinetwegen kann ich auch einen anderen Rechner hinstellen, es fehlt die nicht erfasste Aus-Zeit. Dito bei Stromausfall, wo überhaupt noch zu klären wäre, läuft die Erfassung weiter oder haben wir dann andere Probleme...