Access - monatlich neue DB erstellen

[stephan3309]

Hallo,

zu Anfang,...
...ich kenne mich noch nicht sehr gut mit Delphi aus,...ist größtenteils Neuland für mich.

Ich habe ein Programm geschrieben, welches mir alle 60 Sekunden ca. 15 Messwerte von einer Steuerung (Beckhoff) holt,
und diese in eine Access Datenbank schreibt.
Daraus erstelle ich ein Chart ums anschaulicher zu machen.

Mein Problem:
Theoretisch läuft das Programm 24Stunden, 365Tage im Jahr,... also die Messwerte sollen ständig Aufgezeichnet
werden und zu verfügung stehen, halt eine Prozessüberwachung.
Für rund 10 Jahre müssen die Messwerte dann zu Verfügung stehen

Alle Messwerte werden jetzt nur in einer DB mit 2 Tabellen (die Messwerte stammen von 2 Unterschiedlichen Anlagen, deshalb 2 Tabellen)
gespeichert.

In ca. 1 Jahr wären also 2x 525600 Zeilen in der DB.


Die Lösung die ich Anstrebe zu finden:
1x monatlich die DB kopieren, mit dem Namen von Jahr/Monat abzuspeichern und dann die "Arbeits DB" löschen.

Leider komme ich da nicht so wirklich weiter, :wall: weiß nicht wie ich das angehen soll.
Kann mir vielleicht jemand ein oder zwei Tipps dazu geben?

Mit freundlichem Gruß
Stephan Köster

[Phoenix]

Zitat:

In ca. 1 Jahr wären also 2x 525600 Zeilen in der DB.

Du hast Dich da irgendwo verrechnet:
15 Meßwerte einmal pro Minute * 60 Min (1 Stunde) * 24 (1 Tag) * 365 (1 Jahr) = 7.884.000 also fast schon 7,9 Mio. Datensätze für ein Gerät.

Aber davon mal abgesehen: Datenbanken sind dafür da, große Mengen an Daten zu verwalten. Du willst ja eine Datenbank mit Daten von 10 Jahren anlegen und diese Auswerten können. Da macht es absolut keinen Sinn, die Daten auf 120 unterschiedliche Datenbanken aufzuteilen, über die man nicht einheitlich abfragen kann. Was wäre, wenn jemand einen Durschnitt der Meßwerte pro Halbjahr haben möchste?

Jet ist hier im übrigen wahrscheinlich nicht die richtige Wahl.

Ich würde Dir raten, zu einer richtigen Datenbankengine zu greifen, die für sowas ausgelegt ist. Nimm am besten eine Oracle Express her, die können sehr gut mit so großen Datenbeständen umgehen (ich hab bei einem Kunden eine Datenbank mit Datensätzen im oberen zweistelligen Millionenbereich, und die läuft superstabil und schnell).

[Bernhard Geyer]

Access-Datenbank Erstellen oder du hast einfach eine leere DB "auf Lager" und nimmst diese als Vorlage.

Zitat:

Zitat von Phoenix

Ich würde Dir raten, zu einer richtigen Datenbankengine zu greifen, die für sowas ausgelegt ist. Nimm am besten eine Oracle Express her, die können sehr gut mit so großen Datenbeständen umgehen (ich hab bei einem Kunden eine Datenbank mit Datensätzen im oberen zweistelligen Millionenbereich, und die läuft superstabil und schnell).

Wirklich? Aber auch nur wenn die Datenbank auf einem dedizierten Server läuft und jede Menge RAM besitzt. Gleichzeitig mit einer "normalen" Anwendung laufen zu lassen könnte ein Problem werden wenn man Oracle wieder versucht alles RAM zu reservieren und Windows dann anfangen muss permanent zu swappen.

Hatte erst heute wieder denn Fall das selbst bei einer dedizierten DB man Oracle Problemlos (trotz Optimierter SQL-Strategie) so weit mit Arbeit belegen kann das selbst mit den Oracle-Tools keine Anmeldung mehr an die DB möglich ist. Und das nur mit einer Anwendung von einem PC aus. Man sollte halt Oracle nicht mit zu vielen Inserts in einer Transaktion "quälen".

[Phoenix]

Zitat:

Zitat von Bernhard Geyer

Gleichzeitig mit einer "normalen" Anwendung laufen zu lassen könnte ein Problem werden wenn man Oracle wieder versucht alles RAM zu reservieren und Windows dann anfangen muss permanent zu swappen.

Ich geh bei sowas immer davon aus, dass die Datenbank dann auch richtig konfiguriert ist. Meine Lokale Dev-Ora darf z.B. maximal 180 MB Ram nehmen und that's it. Bei einem Gig Ram und mit noch ner laufenden VM mit 512 MB verbrauch ist das angemessen. Die vorhin erwähnte ist freilich ein dedicated, aber auch da darf die DB nicht mehr als 1,5 GB Speicher ziehen. Rest ist fürs OS da.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von Bernhard Geyer

Gleichzeitig mit einer "normalen" Anwendung laufen zu lassen könnte ein Problem werden wenn man Oracle wieder versucht alles RAM zu reservieren und Windows dann anfangen muss permanent zu swappen.

Ich geh bei sowas immer davon aus, dass die Datenbank dann auch richtig konfiguriert ist. Meine Lokale Dev-Ora darf z.B. maximal 180 MB Ram nehmen und that's it. Bei einem Gig Ram und mit noch ner laufenden VM mit 512 MB verbrauch ist das angemessen. Die vorhin erwähnte ist freilich ein dedicated, aber auch da darf die DB nicht mehr als 1,5 GB Speicher ziehen. Rest ist fürs OS da.

Aber ob bei der erwarteten Datenmenge noch ohne dedizierten Server gearbeitet werden kann wenn alles in eine DB soll (muss?). Der Ansatz ist schon nicht schlecht wenn keine Auswertungen über mehrere Jahre gefahren werden müssen.

U.u. gibt es aber andere Vorteile wenn man sich an eine DB binden will das man auch gleich die Vorteile dieser Nutzt (z.B. Reporting-Services bei neueren MS SQL-Server-Versionen).

Also fragen wir mal nach den Randbedingungen:
- Wird es mehrere Installationen geben?
- Wäre der Installationsmehraufwand für einen richtigen SQL-Server vertretbar?
- Wie soll die Programmverteilung ablaufen?

[stephan3309]

Guten Morgen,

Hallo Phoenix
zu den Randbedingungen:

Zitat:

- Wird es mehrere Installationen geben?

Nein, das Programm soll nur auf einem Rechner laufen.
Evtl. wird es auf ein oder zwei anderen Rechnern nur zur Anzeige der
Messwerte (Temperaturen) genutzt.
Die tatsächliche Temperaturerfassung läuft nur auf einem Rechner.

Zitat:

- Wäre der Installationsmehraufwand für einen richtigen SQL-Server vertretbar?

Leider nein, würd sich nicht realisieren lassen,
deshalb hab ich mich vorerst für Access entschieden
(weil ich mich zum einen mit keiner andern DB auskenne :( ,
und Access auf allen Rechnern installiert ist)

Zitat:

- Wie soll die Programmverteilung ablaufen?

Was meinst du mit Programmverteilung?


Hallo Bernhard Geyer,

Zitat:

Access-Datenbank Erstellen oder du hast einfach eine leere DB "auf Lager" und nimmst diese als Vorlage.

ich habe mir unter Access die DB erstellt und hole mir
die DB einfach via ADO Table in mein Programm.

[mkinzler]

Zitat:

Zitat:

Access-Datenbank Erstellen oder du hast einfach eine leere DB "auf Lager" und nimmst diese als Vorlage.


ich habe mir unter Access die DB erstellt und hole mir
die DB einfach via ADO Table in mein Programm.

Berhard meint eine leere DB mit Bs-Mitteln Umkopierem Umbenennen und dann mit ADO öffnen.

[stephan3309]

Zitat:

Berhard meint eine leere DB mit Bs-Mitteln Umkopierem Umbenennen und dann mit ADO öffnen.

Also müsste ich
- Eine leere DB als Vorlage anlegen,
- Am Ende eines Monats
- Die aktuelle DB-Datei umbenennen (z.B. August_06)
- Die DB-Datei in ein Verzeichnis (z.B. History) kopieren
- eine Kopie der Vorlage in das Arbeitsverzeichnis kopieren

und das innerhalb der 60 Sekunden bis zur nächsten Aktualisierung der DB.

Würd das funktionieren wie ich mir das jetzt vorstelle, oder gibts ne alternative?

[mkinzler]

Zitat:

Würd das funktionieren wie ich mir das jetzt vorstelle, oder gibts ne alternative?

Sollte eigentlich problemlos gehen, sonst lass den Programmteil doch auf einem vergleichbaren Rechner laufen, und stoppe, wie lang er benötigt.
Als Alternative wäre die Neuanlage der neuen Datenbank, was eher länger dauert als das Kopieren einer leeren DB oder das Auslagern der "alten" Daten in eine andere DB ( Neuanlage der alten DB).

[Jelly]

Zitat:

Zitat von stephan3309

und das innerhalb der 60 Sekunden bis zur nächsten Aktualisierung der DB.

Darauf wirst Du achten müssen, weil Du die Datenbankverbindung erst schliessen musst, bevor Du die mdb Datei verschieben kannst. Aber das sollte ja innerhalb von ein paar Sekunden erledigt sein.

• Schliessen
• Umbenennen
• Neue erstellen
• DB Verbindung wieder öffnen
• Alte DB verschieben

[Bernhard Geyer]

Zitat:

Zitat von stephan3309

Zitat:

Berhard meint eine leere DB mit Bs-Mitteln Umkopierem Umbenennen und dann mit ADO öffnen.

Also müsste ich
- Eine leere DB als Vorlage anlegen,
- Am Ende eines Monats
- Die aktuelle DB-Datei umbenennen (z.B. August_06)
- Die DB-Datei in ein Verzeichnis (z.B. History) kopieren
- eine Kopie der Vorlage in das Arbeitsverzeichnis kopieren

und das innerhalb der 60 Sekunden bis zur nächsten Aktualisierung der DB.

Ich würde eh zwischen Datenempfand und Datenspeicherung eine Pipeline einziehen so das die Speicherung Asynchron vom Empfang erfolgen kann. Evtl. den Empfang in einem Thread verlagern. Damit könntest du Problemlos z.B. (wenn es mal gewünscht würde) auch Statistikauswertungen zeitnah nach dem Empfang der Daten fahren.

[stephan3309]

Ui, das war jetzt etwas viel auf einmal :gruebel: , könntes du mir erklären wie du das meinst? (Pipeline, Asyncroner Empfang)

[stephan3309]

So, mit dem kopieren und umbenennen funktionierts.

Jetzt sind nur noch 2 Fragen offen:

- Wie kann ich denn nun herrausbekommen, wann der letzte Tag im Monat ist, um
das kopieren zu starten?

- Wie kann ich die Einträge in der Access DB löschen und gleichzeitig die
DB "aufräumen"?
Als Primary Key habe ich einen AutoWert, der sollte dann auch zurück gesetzt werden,
was er nur tut, wenn ich mit Access eine Reorganisation bzw. Reperatur starte.

[mkinzler]

Zitat:

- Wie kann ich denn nun herrausbekommen, wann der letzte Tag im Monat ist, um
das kopieren zu starten?

Berechnen.

Zitat:

- Wie kann ich die Einträge in der Access DB löschen und gleichzeitig die
DB "aufräumen"?

Delete from ... where datum < ...

Zitat:

Als Primary Key habe ich einen AutoWert, der sollte dann auch zurück gesetzt werden,
was er nur tut, wenn ich mit Access eine Reorganisation bzw. Reperatur starte.

Nein würde ich nicht.

[marabu]

Hallo Leute,

ich habe mir den thread zweimal durchgelesen, aber keine Anforderung entdeckt, die den Einsatz eines DBMS rechtfertigt. Ich würde die beiden Anforderungen - "Aufzeichnung" und "Auswertung" von Messwerten - getrennt umsetzen. Das data logging kann ruhig in eine Textdatei erfolgen. Eine Auswertung oder auch eine Visualisierung wird wohl kaum über ein DBMS erledigt werden. Da bieten sich eventuell spezielle Statistik-Pakete oder auch Software zur Prozessdaten-Visualisierung an oder es genügt sogar eine eigene Anwendung. Bei 15 Messwerten pro Sekunde und 10 Jahren Aufzeichnung scheint mir ein DBMS wirklich nicht das passende Werkzeug zu sein.

Freundliche Grüße vom marabu

[stephan3309]

So,...
das kopieren und umbennenen,
sowie das Löschen der DB einträge funktioniert.
Soweit schonmal Danke!

Nur mit dem Sichern zum Monatswechsel klappts mir nicht.
Wie könnte ich das berechnen?
Hat evtl. jemand einen Beispiel Code für mich?


Hallo marabu,
warum ich Access verwendet habe (verwenden will) liegt einfach daran,
das ich nicht weiß wies anders funktionieren könnte.
Eine DB zum Abspeichern meiner Messwerte fand ich als einfachste
Lösung schnell ein Programm zu schreiben.

Es war erstmal wichtig ein Programm hinzubekommen, wo
unsere Herrschaften was sehen konnten (hauptsache läuft).

Ändern und Optimieren kann ich das ganze jederzeit.

Über alternativ Vorschläge (vielleicht auch Infos zu passenden Turiotals) würd
ich mich natürlich freuen.

[Jürgen Thomas]

Zitat:

Zitat von stephan3309

Nur mit dem Sichern zum Monatswechsel klappts mir nicht.
Wie könnte ich das berechnen?
Hat evtl. jemand einen Beispiel Code für mich?

Wann genau willst Du sichern?
1. mitten in der Nacht um 23:59:01 Uhr?
2. oder um 00:00:01 Uhr?
3. oder am Ultimo zum Arbeitsende, z.B. um 16:59:01 Uhr?
4. oder am Monatsanfang zum Arbeitsanfang, z.B. um 08:00:01 Uhr?

Welche Funktion(en) dies innerhalb der Access-DB regeln könnten, weiß ich nicht; weil als Ergebnis eine neue/leere DB entstehen soll, dürfte die Arbeit sowieso vom Programm aus gesteuert werden. Vorschlag:

Delphi-Quellcode:

function TForm1.Zeit_zum_Sichern: Boolean;
var Year, Month, Day: Word;
    Vergleich: TDateTime;
begin
  //  bei Variante 1 oder 3:
  Vergleich := Now + 1;
  //  bei Variante 2 oder 4:
  Vergleich := Now;
  //  Erklärung: 
  //  TDateTime sind Dezimalzahlen, bei denen der integer-Anteil dem Tag entspricht;
  //  es soll geprüft werden, ob das Vergleichsdatum der Monatsanfang ist
  //
  //  Standardfunktion aus SysUtils teilt das Datum auf:
  DecodeDate(Vergleich, Year, Month, Day);
  //  einfacher Vergleich auf 'Monatsanfang' genügt:
  Result := Day = 1;
end;

Damit könntest Du weiterkommen. Jürgen

[stephan3309]

Hallo Jürgen,
ich hab mir mal folgendes zurecht geschrieben:

Delphi-Quellcode:

function TForm1.Backup: Boolean;
var Year, Month, Day: Word;
    Vergleich: TDateTime;


begin
  Vergleich := Now;
  DecodeDate(Vergleich, Year, Month, Day);
  Result := Day = 1;
end;

procedure Backup_DB;
var clear_DB:Boolean ;
begin
  if TForm1.Backup.Result := 1 then begin
  Dateiname :=  'c:\test\backup\daten' + datetostr(now) + '.mdb';
  copyFileTo('c:\test\db\daten.mdb' , Dateiname );
  clear_DB := 1;
  end;

  if clear_DB := 1 then begin
  DataModule6.ADOTable1.Close;
  DataModule6.ADOTable1.Open;
  DataModule6.ADOCommand1.Execute;
  DataModule6.ADOTable1.Close;
  DataModule6.ADOTable1.Open;
  clear_DB := 0;
  end;

end;

Ich bekomme in der Zeile

if TForm1.Backup.Result := 1 then begin

einen Fehler beim Übersetzen, woran könnte das Liegen?

Könnt ihr sonst noch einen Denkfehler entdecken?

[mkinzler]

Vielleicht weil es

Delphi-Quellcode:

 if Form1.Backup.Result = 1 then begin

oder

Delphi-Quellcode:

 if Form1.Backup = 1 then begin

heißen müsste

[Jürgen Thomas]

Zitat:

Zitat von stephan3309

Ich bekomme ... einen Fehler beim Übersetzen, woran könnte das Liegen?

Könnt ihr sonst noch einen Denkfehler entdecken?

Warum erlaubst Du uns nicht, die vom Compiler gemeldeten Fehler zu lesen? So müssen wir raten...

Allerdings sind diverse Fehler offensichtlich. Ich sehe folgende Problemstellen oder Fehler:

Delphi-Quellcode:

function TForm1.Backup: Boolean;
// ...
procedure Backup_DB;

Backup ist Bestandteil der Klasse TForm1, Backup_DB ist eine (globale?) Prozedur; es bietet sich aber wohl an, beides in derselben Klasse zu deklarieren und zu implementieren - es sei denn, Du willst beides unabhängig voneinander benutzen.

Delphi-Quellcode:

if TForm1.Backup.Result := 1 then begin

Hier gibt es folgende Fehler:
1. Du greifst auf TForm1, d.h. auf eine Klasse zu; Du würdest aber eine Instanz - z.B. Form1 - benötigen.
2. Backup ist eine Funktion vom Typ Boolean. Form1.Backup repräsentiert also bereits einen der Werte true/false.
3. Result kann nur als lokale Variable innerhalb einer Funktion verwendet werden; es ist aber kein Bestandteil einer Klasse TForm1.Backup (das wäre auch ein Widerspruch zur Deklaration als Funktion, also Quatsch).
4. Mit Result := 1 weist Du der (nicht existenten) Eigenschaft Result den numerischen Wert 1 zu.
Da muss der Compiler doch durcheinander kommen.

In der Folge gäbe es weitere gleichartige Probleme:

Delphi-Quellcode:

var clear_DB:Boolean ;
// ...
  if 
// ...
    clear_DB := 1;
  end;
// ...
  if clear_DB := 1 then begin
    clear_DB := 0;
  end;
end;

Bitte nimm Einrückungen vollständig, d.h. auch innerhalb von if...begin/end vor; dann sollten Dir Fehler selbst auffallen:
1. clear_DB ist als Boolean deklariert, bekommt aber numerische Werte zugewiesen.
2. if clear_DB := 1 ist eine Zuweisung einer Zahl, soll aber ein bool-Vergleich sein.
3. Bei der zweiten if-Abfrage ist nicht sichergestellt, dass clear_DB überhaupt einen Wert hat: Es bekommt weder vor der ersten if-Abfrage noch innerhalb eines else-Zweiges einen Wert zugewiesen.
4. Am Ende bekommt clear_DB noch den Wert 0, mit dem Du aber nichts mehr machst. Wozu?

Ich vermute, dass Du Folgendes erreichen willst:

Delphi-Quellcode:

function TForm1.Neuer_Monat: 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;

//  geändert in Funktion innerhalb des Formulars:
//  Rückgabe: Kopie erledigt und bearbeitet ja/nein
function TForm1.Backup_DB: Boolean;
var sDateiname: string;
begin
  //  Result bezieht sich auf die aktuelle Funktion;
  //  Vorgabe: es wurde keine Kopie erstellt
  Result := false;
  //  Neuer_Monat ist der Rückgabewert der o.g. Funktion!!!
  if Neuer_Monat then
  begin
    //  Versuch einer Kopie mit Fehlerprüfung
    try
      //  der Dateiname könnte noch schöner erzeugt werden und benötigt
      //  bei einmaliger Verwendung keine Variable
      sDateiname :=  'c:\test\backup\daten' + datetostr(now) + '.mdb';
      copyFileTo('c:\test\db\daten.mdb' , sDateiname );
      //  wenn kopiert werden konnte
      Result := true;
    except
      //  wenn nicht kopiert werden konnte: Fehlermeldung
      on e:exception 
      do ShowMessage(e.Message);
      //  Result steht weiterhin auf false
    end;
  end;
  //  wenn kopiert werden konnte, dann DB anpassen
  if Result then 
  begin
    try
      //  mit Fehlerprüfung
      DataModule6.ADOTable1.Close;
      DataModule6.ADOTable1.Open;
      DataModule6.ADOCommand1.Execute;
      DataModule6.ADOTable1.Close;
      DataModule6.ADOTable1.Open;
    except
      //  wenn DB nicht bearbeitet werden konnte: Fehlermeldung
      on e:exception 
      do ShowMessage(e.Message);
      //  Result muss jetzt auf false gesetzt werden
      Result := false;
    end;
  end;
end;

Zur Verbesserung könnte man die zweite Funktion noch danach unterscheiden, ob überhaupt nicht kopiert werden sollte (Day <> 1) oder ob nicht kopiert werden konnte oder ob die DB nicht überarbeitet werden konnte. Außerdem kann die erste Funktion lokal in die zweite eingebaut werden (da schreien dann andere User wieder auf - bitte keine neue Diskussion darüber); und je nach Fehlermeldung kannst Du unterschiedlich reagieren.

Aber das solltest Du Dir alles später überlegen. Jürgen

[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...