PDA

Vollständige Version anzeigen : Berechnung von Sondertagen


FW
29.10.2008, 11:20
Einerseits wird hier im Forum immer wieder mal auf Datums-Tabellen verwiesen, mit deren Hilfe sich z. B. entsprechende Abfragen leichter und effizienter gestalten lassen.
Bisher wurden aber solche Tabellen hier nicht veröffentlicht.
Andererseits gibt es auch immer mal wieder Anfragen zu Feiertags- und Werktags-Berechnungen.
Und nachdem die tolle Demo-Datenbank Kalender in Access (http://www.ms-office-forum.de/forum/showthread.php?t=201238) von uwek hier eingeschlagen ist, wie eine Bombe, ist es vielleicht auch von Interesse, die Grundlagen für eine solche Anwendung kennenzulernen.
Deshalb nun die Anwendung Date.mdb.
Diese Anwendung enthält 2 Problemlösungen:
1.) Die flexible Erstellung einer Datums-Tabelle für einen bestimmten Zeitraum (frmCreateDateTab).
2.) Die Generierung von VB-Code zur Berechnung von Sondertagen (frmGenerateDate).
Viel Spaß...

@Lanz Rudolf: Bitte sei diesmal so fair und veröffentliche die beiligende Doku weder ganz noch tw. wieder unter Deinem Namen...

Josef P.
29.10.2008, 12:33
Falls so etwas ähnliches unter T-SQL gesucht ist: FactoryCalendar.sql (http://access.joposol.com/download/FactoryCalendar.sql)

FW
29.10.2008, 23:14
Nachtrag: Um die Tiparbeit zur Erfassung von Sondertagen zu minimieren, hier nochmal die gleiche Anwendung, mit vielen bekannten Sondertagen (tabDatumParameter).
Ach übrigens, die Anwendung liegt als ACC97 vor, um eine größere Kompatibilität zu gewähren...

FW
30.10.2008, 00:52
... leider habe ich gerade einen (kleinen) Fehler bei der Code-Generierung bemerkt, der zwar nur auftritt, wenn Muttertag und Pfingsten auf einen Tag fallen, aber dennoch hier die bugfreie Version mit der Bitte an die Moderatoren, die obigen Download-Links zu löschen. Sorry und vielen Dank...

FW
06.11.2008, 15:34
...leider enthält die Anwendung noch einen Bug: Muttertag und Buß-BetTag werden dann falsch berechnet, wenn der Monatserste auf einen Sonntag bzw. Mittwoch fällt!
Deshalb nun nochmal eine bereinigte Version.
Diese Version enthält zudem noch ein kleines Beispiel für einen Monats-Kalender und einer Tagestermin-Verwaltung mit Erinnerungs-Funktion, die allein auf dem generierten Code aus frmGenerateDate aufsetzen.
In der Dokumentation wird weiter der Algorithmus zu Berechnung von Terminen kurz erläutet.
Deshalb auch nochmal die Bitte an die Moderatoren, den obrigen Download-Link zu löschen.
Nochmals sorry und vielen Dank...

Scorefun
09.11.2008, 16:28
Kompilierfehler: g_cst_Separator variable nicht definiert

edit: gefunden...Variable fälschlicherweise als g_cstSeparator definiert :D

FW
09.11.2008, 23:47
@Scorefun: in der letzten Version?

Inti31
10.11.2008, 16:30
...den Fehler habe ich auch...
Des Weiteren fehlt bei mir die Referenz "Microsoft Dao 2.5/3.51 Compatibility Library".

Selbst ein Setzen auf DAO 3.6 bewirkt keine Besserung.
ich bekomme staendig die Meldung bzgl das ich die Aenderungen nicht speichern kann aufgrund dass die Anwendung in einer frueheren Version erstellt wurde.

Habe hier Access 2000 SR1.

Gruss Inti31

Scorefun
10.11.2008, 17:08
Inti31: musst du konvertieren in A2000

FW: ja, posting #5

FW
10.11.2008, 17:21
... Mutter- und Buß- und Bettag rauben mir noch den letzten Nerv! Ich habe nochmal bei Wikipedia nachgeschaut und musste erfahren, dass der Buß- und Bettag nicht auf den 3. Mittwoch im November fällt, sondern auf den 11. Tag vor dem ersten Advent! Und Muttertag ist immer der zweite Sonntag im Mai, unabhängig davon, ob nun der Pfingstsonntag auch auf diesen Tag fällt oder nicht!
Also habe ich DOC- und MDB-Datei entsprechend angepasst.
Der von Scorefun gemeldete Bug ist nun auch behoben.
Kann mich nur nochmal für das Chaos entschuldigen und, hoffentlich zum letzten Mal, die Modeatoren bitten, den Downoad-Link in #5 zu löschen...

@Init31: Wenn Du die MDB vorher nach Access 2000 konvertierst, sollte es keine Probleme geben! Wenn Du dies nicht tust und die Anwendung als Access 97-Anwendung laufen lässt, dann können unter Access 2000 natürlich keine Änderungen vorgenommen werden!

Scorefun
10.11.2008, 17:47
sorry, der Fehler tritt immer noch auf.

g_cst_Separator -> deklariert als g_cstSeparator

Wenn ich das überall ändere, kommt Fehler bei Get_Kw
(was ich nur als GetKW finde)

Weiter geht's mit Is_Feiertag -> gibt es nur als IsFeiertag

Führe ich den CodeGenerator (frmGenerateDate -> Code) aus, kommt auch ne Meldung, daß er
Modul1 nicht findet; danach sind aber die richtigen Funktionen (Get_KW etc) da...

*grübel*:boah:

Sascha Trowitzsch
10.11.2008, 19:08
Hi FW,

Mach dir mal keinen Stress. Es ist normal, dass nicht gleich alles perfekt ist und Korrekturen vor allem dann erforderlich werden, wenn Andere die Routinen testen. ;)
Die Datumsroutinen sind eh nicht so trivial und im Netz findet man auch diverse falsche Beispiele oder Berechnungsgrundlagen.

Insofern: Warten wir mal ab, bis das Teil rund läuft und DANN lösche ich gerne die restlich verbliebenen Uploads... ;)

Ciao, Sascha

FW
10.11.2008, 19:11
... der Beispiel-Kalender funktioniert erst nach Erstellung des Moduls modDateFuncs via Formular frmGenerateDate (s. a. DOC)!
Der Fehler, dass Modul1 nicht gefunden werden kann, kann ich unter A97 nicht nachvollziehen, muss ich dann wohl mal in A00 testen...

Scorefun
10.11.2008, 19:40
sollte auch nix negatives rüberkommen...;)

ich kenne das ja selber, daß ich in der firma was veröffentliche, und erst beim
täglichen gebrauch die fehler auftauchen...

FW
10.11.2008, 22:23
@Scorefun: Also bei mir ist gar nichts negativ rübergekommen. Im Gegenteil, danke für Dein Feedback! Ich wundere mich eher umgekehrt, dass die Leute, die sich die bugigen Daten runtergeladen haben, nicht nachfragen.
Das löst aber nicht Deine Fehler-Meldung (Modul1). Wie lautet denn die Zeile, in der der Fehler auftritt?
Die anderen Fehlermeldungen treten beim Konvertieren auf? In der Tat ist es so, dass das Beispiel-Formular frmKalender ohne das Modul modDateFuncs nicht kompilierbar ist und deshalb wohl die Fehler auftreten.
Wenn Du die Objekte einzeln in eine leere MDB importierst, sollte es klappen...

Scorefun
11.11.2008, 17:18
Hallo FW,

leider lässt mich Access 2003 bei diesem Code nicht im Debug-Modus durchzulaufen.
Es scheint aber am Umbennen des Moduls am Schluss zu liegen :

DoCmd.Rename cmdCode.ControlTipText, acModule, modVar.Name

Zur Laufzeit enthalten die beiden Variablen dann :

cmdCode.ControlTipText = modDateFuncs
modVar.Name = Modul1

was ja eigentlich auch richtig ist.

Ich habe allerdings herausgefunden, daß das Modul wohl deshalb nicht gefunden wird,
weil es noch nicht gespeichert wurde.
Die Zeile

DoCmd.Save acModule, modVar.Name

vor dem Umbenennen hinzugefügt : und es läuft fehlerfrei durch...

FW
11.11.2008, 22:53
Hallo Ralf,
danke für Dein Feedback, hast Dich ja echt mit der Sache beschäftigt.
Dennoch verstehe ich das Verhalten unter A03 nicht so ganz. Mit der Close-Anweisung sollte das Modul doch eigentlich auch gespeichert werden?! Hast Du die Save-Anweisung tatsächlich vor die Rename-Anweisung gesetzt? Der Code sieht nun also so aus?
...
DoCmd.Close acModule, modVar.Name, acSaveYes
DoCmd.Save acModule, modVar.Name
DoCmd.Rename cmdCode.ControlTipText, acModule, modVar.Name
...
Das würde bedeuten, dass die Close-Anweisung unter A03 nicht sauber arbeitet?
Warum kannst Du unter A03 "diesen Code" nicht debugen? So exotisch ist der doch nun auch wieder nicht, als dass ein Debugger diesen verweigert? :upps:
Es ist ja nicht so, dass ich nicht noch 'n Save einbauen könnte, aber ich würde schon gerne wissen, wo der Fehler liegt. Hab' mit A03 praktisch keine Erfahrung, hat nur bis A00 gereicht. ;)
Vielen Dank für Deine Mitarbeit
Frank

Josef P.
12.11.2008, 00:24
@Frank: wie hast du die Ac97-mdb erstellt? Durch Konvertieren aus Ac00?
Denn wenn ich die mdb unter Ac97 öffne, gibt es einige Fehlermeldung, wenn ich die Module kompiliere. Das führt dann auch dazu, dass bei der Konvertierung in eine höhrere Version eine Fehlermeldung kommt.

folgende Ersetzungen musste ich durchführen:
g_cst_Separator => g_cstSeparator
Get_Kw => GetKw
Is_Feiertag => IsFeiertag
Fill_Bundesland => ???
g_cst_Baden_Württemberg => g_cstBaden_Württemberg
g_cst_Thüringen => g_cstThüringen
g_str_Bundesland => g_strBundesländer

FW
12.11.2008, 01:48
... nee, das liegt daran, wie ich zuvor schon versucht habe deutlich zu machen, dass das Formular frmKalender Aufrufe enthält, die erst noch mit dem Formular frmGenerateDate erstellt werden müssen! Mit dem Formular frmGenerateDate wird das Modul modDateFuncs erstellt, welches dann die fehlenden Routinen enthält! Ist vielleicht nicht ganz glücklich, aber ich wollte so demonstrieren, das mit diesem Modul dann völlig autark gearbeitet werden kann. In diesem neu erstellten Modul ähneln die Konstanten- und Routinen-Namen den Namen aus modDate, welches für die Erstellung der Tabelle tabDatum benötigt wird. Hätte ich vielleicht ein wenig geschickter machen sollen, aber ich wollte erreichen, dass der interessierte Benutzer so sehen kann, dass ein neues Modul nach seinen erfassten Sondertagen erstellt wird.
Also nochmal:

Für das Erstellen der Tabelle datDatum ist das Formular frmCreateDateTab und die Module modApp und modDate nötig. Das Modul modTabFuncExamples enthält einige Beispiele, die dann, nach Erstellung der Tabelle tabDatum, zeigen sollen, wie nun mit dieser Tabelle gearbeitet werden kann. Was natürlich auch fehlschlägt, wenn diese Tabelle vorher nicht erzeugt wurde.

Für das Erstellen des Modules modDateFuncs ist die Tabelle tabDatumParameter, das Formular frmGenerateDate und das Modul modApp notwendig.

Für das Beispielformular frmKalender und das Formular frmTermine ist die Tabelle tabTermine und allein das zu erstellende Modul modDateFuncs notwendig.

Ich habe in der Tat nicht daran gedacht, dass eine nicht kompilierbare Anwendung entsprechende Fehlermeldungen beim Konvertieren verursacht, aber wird die Konvertierung dann abgebrochen?
Wenn ja, können dann nicht auch die einzelnen Objekte in eine höhere Version importiert werden? Kann das momentan nicht testen, weil ich auf einem alten Rechner arbeite und deshalb kurzfristig nur A97 zur Verfügung habe.
Ich hoffe, dass nun ein wenig Licht ins Dunkel gekommen ist und danke Dir für Deine "späte" Aufmerksamkeit
Gruß
Frank

Josef P.
12.11.2008, 09:47
Die konvertierte mdb scheint auch nach der Fehlermeldung zu laufen.
BTW: ich musst aber zuvor die Fehlerbehandlung von "bei jedem Fehler unterbrechen" auf "bei nicht verarbeiteten Fehlern unterbrechen" umschalten.
Auch ein Kompilieren vor Code-Ausfürhung darf man nicht machen, sonst glaubt man das sei nicht funktionierender Code. :)

übrigens:
DoCmd.Save acModule, modVar.Name
ist auch bei mir unter AcXP erforderlich.

Scorefun
12.11.2008, 11:53
Wie Josef schon sagte, ist unter A03 ein Speichern des Modules erforderlich,
bevor umbenannt werden kann.

Die Zeile
DoCmd.Close acModule, modVar.Name, acSaveYes
braucht man da dann wohl nicht.

Kannst Du ja mal unter A97 auch so ändern, ob es dann immer noch durchläuft.

Bzgl. Debuggen :
Es war mir nicht möglich, im Unterbrechungsmodus per F8 durch den Code
zu steppen.
Es kam dann die Meldung "Wechsel in den Haltemodus ist zu diesem
Zeitpunkt nicht möglich" in der Zeile

modVar.insertLines ...

Aber es klappt ja jetzt...
Ich kann es auf jeden Fall gut gebrauchen.:winner:

FW
16.11.2008, 23:34
... nach der doch etwas chaotischen Veröffentlichung der o. Anwendung, habe ich diese nun in fünf Anwendungen aufgeteilt.

1.) CreateDateTable.mdb
Hier kann eine Datumstabelle (tabDatum) mit verschiedenen Informationen erstellt werden.
2.) CreateDateFuncModule.mdb
Hier können Sondertage erfasst und VB-Code hierfür (modDateFuncs) generiert werden.

3.) KalenderDemo1.mdb
Beispiel eines Monatskalenders, der allein auf der Datumstabelle aus 1.) basiert.
4.) KalenderDemo2.mdb
Beispiel eines Monatskalenders, der allein auf dem generierten Modul aus 2.) basiert.
5.) KalenderDemo3.mdb
Beispiel eines Monatskalenders, der, anhand der in 2.) erfassten Sondertage, zur Laufzeit die entsprechenden Tage berechnet.
An dieser Stelle möchte ich Josef P. für seine Inspirationen danken, aufgrund derer dieses Beispiel entstanden ist.

Ich denke, dass das Ganze nun ein wenig deutlicher und überschaubarer wird...