Office: (Office 2003) Datum addieren ohne Wochenende

Danke Josef, hatte schon gedacht das ich völlig Banane bin.

Ergänzend sollte ich vielleicht noch anmerken , dass die Datensätze mit den Datumswerten noch keine redundanten Daten darstellen. In meinen Kalendertabellen speichere ich aber noch den Wochentag, die Kalenderwoche und die Monatsnummer inkl. Index auf diese Felder ab, obwohl das aus dem Datumswert berechenbar wäre, damit ich die Tabelle für schnelle Auswertungen nutzen kann.
... diese redundanten Daten werden bei mir allerdings nur vom DBMS verwaltet und können vom Benutzer nicht bearbeitet werden, womit dann auch keine falsch zusammenhängenden Werte erzeugt werden können.

 

Hallo zusammen,

@Rainer:

Diese Formel hatte ich auch schon gefunden. Da ich aber kein Programmier-Profi bin, würde ich nun gerne wissen wie ich meinen Code für das Feld NächstePrüfung= DatAdd („m“; [Prüfungsintervall];[LetztePrüfung] in diesen Code miteinbaue?

@ARTUS:
Die Jahrestabelle habe ich nun gebastelt, aber ich verstehe nicht so ganz an welcher ich jetzt den Code einbauen soll.

Danke für eure Hilfe.

Gruß
Eva

 

\@Eva:

Irgendwo willst du doch den nächsten Prüftermin ermitteln. Da muss der Code rein. Bisher ist das eine Abfrage; wenn du das lieber als Funktion haben willst, auch kein Problem:


Code:

Ergibt (wenn wir mal nur Sa und So als arbeitsfrei annehmen):

'nach vorne
? DateAddEva("m",1,"22.01.2009",True )
20.02.2009

'nach hinten
? DateAddEva("m",1,"22.01.2009",False)
23.02.2009

Die Domänenfunktionen sind allerdings recht lahm. Es gibt aber Ersatzfunktionen mit (permanentem) Recordset. Und natürlich geht es auch ganz ohne VBA: per SQL (Abfrage).

 

\@ ebs

Zitat von Atrus:

@ Josef P.

Das ist mit Sicherheit ein Argument das sticht, zumindest mal die Auswertungsflexibilität. *wink.gif* Als fauler Programmierer ist die Vorstellung alle denkbaren Abfragemöglichkeit per VBA-Funktion zu erstellen natürlich eine grausame Vorstellung.

Mit der Geschwindigkeit kann ich nicht so wirklich beurteilen, weil es ja von vielen Faktoren abhängt … wo liegt das BE etc.. Zumindest mit einer FCount-Funktion verglichen (Abfrage so: FCount = DBEngine(0)(0).OpenRecordset(strSQL, dbOpenForwardOnly)(0)) gibt es keinen Zeitunterschied der messbar wäre ob ich nun per dieser FCount Funktion die Abfrage durchführe oder per VBA-Code berechne … liegt alles beides unterhalb von 0 Millisekunden.

Wobei das BE bei mir nicht auf einem Netzwerkserver liegt und FCount nur eine Tabelle mit 1 Jahr durcharbeiten musste.

Da hatte ich eben vermutet das eine VBA-Funktion schneller wäre, die arbeitet ja nur die angegebenen Datumsbereiche ab und muss nicht die komplette Tabelle abarbeiten (okay, da reden wir auch nicht über so irre viel DS …. Selbst nach 20 Jahren sind das ja maximal 7300 und ein paar geklemmte ^^) und hatte nicht die Zugriffsbremse wenn das BE auf einem Netzwerkserver liegt.

Hatte ich mir so auch gedacht, da es ansonsten ja nicht wirklich Sinn machen würde wenn man schon eine Kalendertagstabelle führt die einzelnen „Eigenschaften“ eines Datums zusätzlich zu berechnen.

@ sw-blitz007

Da glaube ich liegt der Hase begraben. *wink.gif*

@ Atrus

Da bin ich auf jeden Fall bei Dir. *wink.gif*

Ein Datum an dem nix ist, ist schlicht ein Dummy-DS. Und solange er nix beinhaltet hat er ja auch keinerlei Einflussgröße für eine Zeitplanung … ein normaler Montag ist halt ein normaler Montag.

Aber Josef hat ja ein entscheidendes Argument gebracht … die Abfrageflexibilität und Du hattest ja die Flexibilität so einer Kalendertagstabelle auch schon genannt.

@ Eva

Code:

So kannst Du die Funktionen IsFeiertag und IsWeekend zu einer Gesamtprüfung zusammen basteln die als Ergebnis einen Werktag zurück gibt.

Der Aufruf der Funktion sollte in etwa so aussehen:

Code:

Das wichtige ist die Übergabe von dteNext, die Variable muss in der aufrufenden Sub deklariert sein und wird mit dem letzten Prüftermin als Inhalt übergeben.

Nach dem Aufruf der Sub hat dteNext den berechneten Werktag als Inhalt.

Gruß

Rainer

 

oha, ich glaube da unterschätzt du ein Datenbanksystem.
Warum sollte das DBS auf die Idee kommen, bei einer Tabelle alle DS abzuarbeiten? DBS sind grundsätzlich faul und suchen sich je nach Filterbedingung den passenden Index um keine unnötigen Wege zu laufen. *wink.gif*

Wenn du allerdings nur vor hast, die Datumswerte per VBA in Variablen abzulegen und dann erst wieder mit VBA weiterarbeitest, ist eine Kalendertabelle kaum ein Geschwindigkeitsvorteil. Der Vorteil ergibt sich hauptsächlich durch die Verwendung in SQL-Anweisungen - also bei Datenbanktechnik.


[OT]

Ui, eine negative Dauer? .. cool. *biggrin.gif*

 

Fundamentales Missverständnis. Ein solcher Satz ist allenfalls "verwaist", weil er derzeit nirgends benutzt wird. Er kann aber jederzeit benutzt werden, z.B. wenn es darum geht, Termine an jedem ersten Montag im Monat anzusetzen (wenns kein Nichtarbeitstag ist).

Dummysätze sind für mich Sätze, die wechselnde Bedeutung haben, etwa der beliebte "Kunde Anonymus", der für Bargeschäfte (anne Bratwurstbude) genutzt wird, weil man für Laufkundschaft keine Kundensätze anlegen kann. Anonymus ist aber kein Kunde, sondern ein Surrogat, ein Artefakt. Alle Kunden der Pommesbude heißen gleich - für die Datenbank. Sie sind ununterscheidbar. Sie sind Dummies.

Auch beliebt:
"Kategorie 999" für "alles mögliche" (das ist keine Kategorie)
"Währung 4711 für Systemwährung" (das ist keine Währung)

 

Mein Gott nimmst Du es aber genau heute ... okay, korrekter formuliert ... bei beiden Versuchen war die Zeitdauer nicht mehr in Millisekunden zu messen oder bei beiden Versuchen war der Zeitbedarf der Bruchteil einer Millisekunde.

Jetzt okay? *g*

Okay, so gesehen habe ich dann die falsche Terminologie angewendet.

Aber verwaist würde ich es auch nicht nennen, sondern eher ein leerer DS. Okay ... wäre auch nicht richtig, da er ja zumindest einen Datumswert beinhaltet. ^^

Einigen wir uns auf: leerer Container für mögliche Datumseigenschaften ... das trifft es wohl am ehesten.

Aber an solchen Beispielen wird klar wann und unter welchen Umständen so eine Tabelle am ehesten Sinn macht. Sowas ist mit einer einzigen SQL-Anweisung machbar.

Gruß

Rainer

 

\@Rainer
Soweit habe ich den Code zwar verstanden, aber ich hab noch eine Frage zur Formel:

Wo gebe ich denn an, dass intIntervall gleich dem Wert der Optionsgruppe[Wartungsintervall] ist und müsste nicht das letzte dteNext irgendwie anders benannt werden.
Da meine Ausgangsformel ja wie folgt lautet: Code:

Gruß Eva

 

Nein, wieso?

In der aufrufenden Sub deklarierst Du dteNext und füllst dteNext mit dem Letzten Prüftermin. In der Prozedur selber wird dann der um den übergebenen Intervall in Monaten raufgezählt (kann man aber auch so abändern, dass der Zeitraum mit übergeben wird also m für Monate etc.). dteNext wird jetzt solange bearbeitet bis es als Inhalt einen Werktag hat und dann endet die Prozedur. Jetzt hat dteNext in der aufrufenden Sub das Datum angenommen das in der Prozedur als Werktag festgestellt wurde.


Code:

Würde dann in etwa so aussehen:

Code:

Allerdings wie die Werte Deiner beiden Felder genau dahin kommen, dafür weiss ich zu wenig.

Ist z.B. NächsteWartung ein Formularfeld, dann müsste es so heissen:

Code:

Wäre jetzt gleich mit Prüfung ob das Feld überhaupt einen Inhalt hat und ein Datum ist.

Beim Abfragen von optionsgruppen muss ich tatsächlich passen ... ich nutze die Dinger nie. *wink.gif*

Gruß

Rainer

 

\@Rainer:

Hab es jetzt mal ausprobiert und nun kommt folgender Fehler, wenn die Prozedur gestartet wird:
NextCheckDay --> Argument ist nicht optional

Wann hat das zu bedeuten?

Gruß Eva

 

\@ Eva

Die Prozedur NextCheckDay erwartet 3 Übergaben ... dteNext, eine Integerwert für den Intervall und ein True oder False.

Nur mit Angabe aller 3 Parameter kannst Du die Prozedur aufrufen. Habe die Parameterübergabe nicht Optional gemacht, deswegen gibt es einen fehler wenn auch nur ein Übergabeparameter fehlt.

Gruß

Rainer