AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Auf Zeitpunkt überwachen

Ein Thema von DaSchwoa · begonnen am 19. Nov 2020 · letzter Beitrag vom 20. Nov 2020
Antwort Antwort
DaSchwoa

Registriert seit: 15. Sep 2020
13 Beiträge
 
#1

Auf Zeitpunkt überwachen

  Alt 19. Nov 2020, 12:45
Hallo
Ich schreibe gerade einen Service und möchte, dass zu einer Bestimmten Uhrzeit eine Prozedur ausgeführt wird.
Bisher habe ich immer einen Timer verwendet. Jede Stunde überprüfen er ob -> (ausgewählt Zeit < Jetzt) dann soll er die Prozedur ausführen.

Jedoch habe ich schon oft gelesen, dass man bloß keinen Timer verwenden soll aber ich kenne auch keine Alternativen. Hätte auch überlegt mit Windows Aufgabenplanung, jedoch habe ich unterschiedliche Zeiten, welche ich aus einem .ini File auslese.

Kann mir da wer weiter helfen?
  Mit Zitat antworten Zitat
generic

Registriert seit: 24. Mär 2004
Ort: bei Hannover
2.398 Beiträge
 
Delphi XE5 Professional
 
#2

AW: Auf Zeitpunkt überwachen

  Alt 19. Nov 2020, 12:59
Den Link zu Cromis „CRON Scheduler“ in den Artikel auf der "entwickler.de" Webseite besser NICHT verwenden!

Ich hatte einen Artikel zu dem Thema verfasst:
https://entwickler.de/online/develop...al-114967.html

bzw. die Papier-Version:

Entwicker 4.2013
https://kiosk.entwickler.de/entwickl.../back-in-time/

Zusammenfassung:
Du kannst den Windows Scheduler nutzen und mit Delphi die passenden Triggern erstellen, wie diese in deiner INI sind.

Cromis kann jetzt hier gefunden werden:
https://github.com/elvac/CromisLibrary
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
5.888 Beiträge
 
Delphi 10 Seattle Enterprise
 
#3

AW: Auf Zeitpunkt überwachen

  Alt 19. Nov 2020, 13:05
Jetzt würde mich aber wirklich der Grund interessieren weshalb man denn keinen Timer verwenden solle...
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.037 Beiträge
 
Delphi 7 Professional
 
#4

AW: Auf Zeitpunkt überwachen

  Alt 19. Nov 2020, 13:16
Also, das mit dem Timer = seeeeehrrrr böööse halte ich für Quatsch.

Seit gefühlt 25 Jahren nutze ich Timer, ohne dass dabei je ein Problem aufgetreten ist.

Auch in Services hab' ich schon Timer genutzt, problemlos, um damit zu steuern, wann welche Aufgabe zu erledigen ist, z. B. 1 Job um 0:00 Uhr, ein anderer um 3:00 Uhr, weitere stündlich, jeweils zur vollen Stunde plus 15 Minuten (also immer um viertel nach), .... Alles in einem Service. Und der lief über viele Jahre anstandslos.

Zum Zeitpunkt:

Die Zeit in Millisekunden bis zum verlangten Zeitpunkt ausrechnen. Beim Timer das Intervall mit der berechneten Anzahl von Millisekunden belegen und den Timer aktivieren. Der "Auslösefehler", die Pünktlichkeit, liegt in 'nem Bereich von +/- 1 Millisekunde. Wenn man's nicht genauer braucht, sollte das reichen.

Um's zu vereinfachen, kann man sich auch 'nen Nachfolger vom TTimer bauen, der beim Aktivieren (timer.Enabled := True) selbst die Zeitdifferenz ausrechnet und das Intervall setzt und dann die Aktivierung durchführt.

In der Timerroutine wird zuerst der Timer deaktiviert, dann die auszuführende Aufgabe (Prozeduraufruf(e)) erledigt, die Zeit bis zum nächsten Aufruf des Timers berechnet, das Intervall gesetzt und der Timer aktiviert.

Ok: Das heißt dann auch: Pro Job ein Timer, solang man da nicht hunderte von Timern in einem Service nutzt und die nicht alle zeitgleich "zuschlagen", geht das ohne weiteres.

Muss man halt 3 mal täglich zu definierten Zeiten 'ne Datei aus dem Web laden und einmal täglich die verarbeiteten Ergebnisse in 'ner Datenbank speichern und dann daraus einen Report an 'nen bestimmten Mailverteiler senden, sowie 'ne CSV-Datei mit dem Ergebnis an einer bestimmten Stelle im Netz ablegen, ..., geht das. Für zeitkritische Aufgaben ist sowas natürlich nicht geeignet.

Jetzt würde mich aber wirklich der Grund interessieren weshalb man denn keinen Timer verwenden solle...
Das ist ja das Schöne, man ließt immer nur: Bööööse, darf man nicht. 'ne (wenn auch nur halbwegs) plausiblen Grund hab' ich bisher noch nicht gelesen
  Mit Zitat antworten Zitat
DaSchwoa

Registriert seit: 15. Sep 2020
13 Beiträge
 
#5

AW: Auf Zeitpunkt überwachen

  Alt 19. Nov 2020, 13:29
Also, das mit dem Timer = seeeeehrrrr böööse halte ich für Quatsch.
Danke die Bestätigung habe ich gebrauch . Jetzt schwimme ich auch gegen den Strom
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
39.424 Beiträge
 
Delphi 11 Alexandria
 
#6

AW: Auf Zeitpunkt überwachen

  Alt 19. Nov 2020, 15:30
Das Schöne mit den CRON-Jobs: Wenn kaum etwas gemacht wird, dann braucht der Service/Hintergrundaufgabe auch nicht dauerhaft "aktiv" zu sein.
Dein Programm ist nicht akiv, es wird vom Aufgabenverwaltungsdienst entsprechend der einstellten Zeiten und/oder Events gestartet und wenn fertig, beendet es sich wieder.
"nicht aktiv" = garnicht aktivt, also beendet und auch nicht nur "nichtstuend" sinnlos wartend.

Windows bietet sogar einen Hintergunddienst für Downloads, wo man ewas eintragen kann und wenn es dann da ist, wird das eigene Programm gestartet.
Netterweise werden hier sogar die DialUp-Settings der Netzwerkverbindung beachtet. z.B. das WLAN des HandyHotspots wird nicht mit Updates überflutet und der Traffic aufgebraucht, sondern erst daheim im großen Internetzugang.

Per se wäre es also garnicht nötig, dass man z.B. Dauerhaft mit tausenden aktiven Diensten/TrayIconProgrammen für Updates von irgendwelchen Programmen zugemüllt wird, die ständig im Internet rumwühlen.


Bei uns läuft im Service ein Thread, da einige Dinge auch minütlich erledigt werden.
Nach jedem Durchlauf macht der mindestens 15 Sekunden und maximal bis zu 60 Sekunden (seit Beginn des Durchlaufs) Pause, als Sicherheit, falls mal irgendwas schief läuft und somit nicht dauerhaft alles auslastet.
Und da werden auch paar Methoden mit aufgerufen, Aktionen in größeren Intervallen -> jeweils am Anfang eine Prüfung, ob Now/CurrentTime größer/gleich dem Zeitpunkt der nächsten Ausführung.
z.B. if (HourOf(Now) = 3) and (LastDate < Date) then begin LastDate := Date; ....... end; // also immer früh um 03:00
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (19. Nov 2020 um 15:33 Uhr)
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
3.434 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: Auf Zeitpunkt überwachen

  Alt 20. Nov 2020, 06:45
Die Zeit in Millisekunden bis zum verlangten Zeitpunkt ausrechnen. Beim Timer das Intervall mit der berechneten Anzahl von Millisekunden belegen und den Timer aktivieren.
So würde ich das für exaktes Timing aber nie machen.
Immer nur den Timer als "Ticker" verwenden, und die Auslösezeit per TDateTime Variable festlegen.

Den "Ticker" kann ich mit der gewünschten Genauigkeit laufen lassen,
gerne auch mit variablen Intervallen
(z.B. 15 Min Intervall, wenn noch > 1 Tag Differenz, 1 Min Intervall am selben Tag).

Dann im Timer die Zeit prüfen:
Delphi-Quellcode:
procedure Timer1Timer( ... );
begin
    Timer1.Enabled := False;

    if Now >= FDateTimeAlarm then
    begin
        TueWasDuNichLassenKannst;
    end;

    Timer1.Enabled := True;
end;

So bestimme ich selbst die gewünschte Genauigkeit, auf die direkte Millisekunden verlasse ich mich nur wenn das Intervall im einstelligen Minutenbereich liegt.
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.037 Beiträge
 
Delphi 7 Professional
 
#8

AW: Auf Zeitpunkt überwachen

  Alt 20. Nov 2020, 09:08
Kommt drauf an, was man machen will.

Zum Dateidownload, 'ner einmal täglichen Datenbankabfrage mit Versand des Ergebnisses per Mail und ca. alle 15 Minuten zu prüfen, ob bestimmte Server erreichbar sind, reicht meine Variante aus. Sie ist einfach, schnell implementiert und lief bisher über Jahre genau und absolut zuverlässig und resourceschonend. Mehr brauch' ich nicht. Bei der Aufgabenstellung wären auch Rundungsdifferenz in der Zeitpunktberechnung von 'ner Minute absolut unkritisch gewesen.

Ob 'ne Prüfung auf Serververfügbar nun zur exakten vollen, viertel, halben und dreiviertel Stunde läuft oder plus/minus 'ne Minute, ist hier irrelevant und 'ne Abweichung von einer Millisekunde ist absolut vernachlässigbar. Und ob die Datenbankabfrage nun jeden Morgen um 03:15 Uhr durchgeführt wird oder 'ne Minute vorher oder nachher ist auch wurscht, zumal man eh nicht kalkulieren kann, wie lange sie genau dauern wird, wieviele Mails aus dem Ergebnis entstehen und versand werden müssen.

Es ging bei meinem Vorschlag nicht um exaktes Timing (wie es für zeitkritische Aufgaben erforderlich sein kann), sondern um eine zuverlässige Regelmäßigkeit. Und die hat die implementierte Variante über Jahre hinweg bewiesen.

Achso: Das "Pollen" auf den exkten Zeitpunkt per immer wieder Abfragen, ob der Zeitpunkt erreicht ist und dabei die Zeiträume zwischen den Abfragen immer weiter verkürzen, bis der Zeitpunkt erreicht ist, war bei den ersten Experimenten in der Implementierung aufwändiger, aber letzlich nicht genauer.

Klar, wenn jemand zwischenzeitlich mal die Systemuhrzeit verstellt, bleibt das Pollen genau und meine Routine geht einmal (ggfls. um die Differenz zwischen Uhrzeit vor der Zeitumstellung und nach der Zeitumstellung) schief, aber dann passt es wieder. Und mehr Genauigkeit war nicht erforderlich.

Es kommt bei der gewählten Methode also drauf an, was man wie genau (oder ungenau) erreichen will.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:39 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf