Hallo Zusammen,
ich möchte gerne meine Urlaubsdatenbank verbesseren.
Hierzu brauch ich mal bitte eure Hilfe.
Ich hab folgende Daten
Name_Mitarbeiter = Hr. Mustermann
Urlaub_von = 24.12.2012 ( erster Ulaubstag )
Urlaub_bis = 03.01.2013 ( letzter Urlaubstag ) also am 04.01 erscheint der Ma wieder
Ich hätte dies nun gerne in einer Tabelle wie folgt dargestellt :LfdNr Name_Mitarbeiter Urlaubsdatum Anzahl_Tage
-------------------------------------------------------------------------------------
1 Hr. Mustermann 24.12.2012 1
2 Hr. Mustermann 25.12.2012 1
3 Hr.Mustermann 26.12.2012 1
4 Hr.Mustermann 27.12.2012 1
5 Hr.Mustermann 28.12.2012 1
6 Hr.Mustermann 29.12.2012 1
7 Hr.Mustermann 30.12.2012 1
8 Hr.Mustermann 31.12.2012 1
9 Hr.Mustermann 01.01.2013 1
10 Hr.Mustermann 02.01.2013 1
11 Hr.Mustermann 03.01.2013 1
jemand eine Idee wie die Anfügeabfrage aussehen muss :
Bin bisher soweit :)
Zitat
Dim strSQLB As String
strSQLB = "INSERT INTO STAMM_URLAUBSPLAN (USER_ID, Urlaubs_Datum)" & _
"SELECT DISTINCT U_Stamm_User.LfdNr," & Format(Nz(Me.Urlaubs_von_Datum, Date), "\#yyyy-mm-dd\#") & " As Datumsfeld FROM U_Stamm_User;"
CurrentDb.Execute strSQLB, dbFailOnError
Me.U_URLAUB_ERFASSUNG_STAMM_URLAUBSPLAN_UFO.Requery
Also den ersten Tag kann ich damit schon mal anlegen :-)
Danke für eure Mühe und Antworten
Lg Bernie
Hallo,
wo nix ist, kann auch nix angezeigt werden....
soll heißen, die Zwischentage als solche gibt es nicht .
Um eine ähnliche Darstellung mittels Abfrage zu erhalten, muss eine "(Betriebs)Kalendertabelle" mit fortlaufendem Datum(seintrag) existieren. Das hätte auch den Vorteil, dass Feiertage und sonstige Tage, die gar keine Urlaubstage sind, außer Acht gelassen werden können, z. B. für die Berechnung der Anzahl Urlaubstage, die ein MA im betrachteten Zeitraum genommen hat
Hallo Franz,
die Folgetage können also nicht einfach so berechnet werden oder ?
Ich hatte mir das so vorgestellt.. die Folgetage werden einfach berechnet. In dieser Tabelle stehen dann wirklich nur Urlaubstage..
Hab auch eine Feiertagstabelle..per Abfrage könnte man die Tage die eben Feiertag oder Änlichem entsprechen herraus nehmen.
Zitat"(Betriebs)Kalendertabelle" mit fortlaufendem Datum(seintrag) existieren.
Ok, die könnte man ja erstellen.. Man hat dann aber jede Menge DS in der DB .je Jahr 345 ...und wenn das letzte Datum erreicht ist muss man manuell jedesmal neue hinzufügen.
Wenn nicht anderes möglich ok.. was solls.
Und wie würde es dann weitergehen ?
Lg Bernie
INSERT INTO STAMM_URLAUBSPLAN (Urlaubs_Datum)
SELECT DateAdd("d", T.I, U.Urlaub_von) AS UTag
FROM tblUrlaube U, T1000 T
WHERE T.I Between 0 AND DateDiff("d", U.Urlaub_von, U.Urlaub_bis)
Weitere Felder kannst Du selbständig ergänzen.
Vergleiche dazu auch SQL-Rezepte (http://www.office-loesung.de/ftopic108646_0_0_asc.php) einschließlich der dort beschriebenen Tabelle T1000.
Mit dem gleichen Verfahren kann man natürlich auch eine (vollständige) Kalendertabelle füllen, um diese per Abfrage mit der Urlaubstabelle unter Abzug von Wochenenden und Feiertagen zu verknüpfen und so z.B. echte Urlaubstage zu ermitteln.
MfGA
ebs
Hallo Ebs,
also bisher verstehe ich nur Bahnhof :-)
hab mir das mit T1000 angesehen. aber verstehen..puh...nein..
ZitatFROM tblUrlaube U, T1000 T
Ist das eine Tabelle wie sie Franz meinte ?
Gruss
Bernie
Was ist an einer Tabelle mit einem einzigen Feld, das als Werte die Zahlen 0 bis 999 enthält, nicht zu verstehen. Falls Dir die DDL-Anweisungen (Data Definition Language) suspekt ist, kannst Du Dir sicher eine Tabelle per Hand bauen und füllen, oder?
Sinn der ganzen Maßnahme ist es, über eine einmalig erstellte und vielfältigst wiederverwendbare Zahlentabelle Tabellen/Abfragen nach eigenem Gusto erzeugen zu können, weil sich viele Datensätze auf einmal besser und vor allem schneller an eine Zieltabelle anfügen lassen als viele einzelne Datensätze in Schleife (Einzelverarbeitung).
ZitatIst das eine Tabelle wie sie Franz meinte ?
Nein. Das ist noch eine direkte Antwort auf Deine ursprüngliche Anforderung, wobei die Werte von und bis einer Tabelle entnommen wurden, was auch die Möglichkeit eröffnet, mehr als einen Datensatz (Urlaubszeitraum) auf einmal zu verarbeiten.
In Datenbanken arbeitet man besser und schneller mit Datenmengen (Massendatenverarbeitung) statt mit einzelnen Werten: Bagger statt Sandschaufel. Es sei denn, man will sich bewusst viel Zeit nehmen.
MfGA
ebs
Hi Ebs,
ok, ich verstehe wo hin der Weg gehen soll-
ZitatBagger statt Sandschaufel
Mir fehlt nur der Bagger
Das ist völligstes Neuland für mich.
Ich mach ja gerne alles was Ihr zu mir sagt. Wenn du die Geduld aufbringst und mit mir das zuerarbeiten, wäre ich dir sehr dankbar.
Bin halt ein Noob :-)
also ich brauch eine Tabelle die T1000 heisst und ein Zahlenfeld mit dem Namen "T" hat.
in "T" müssen die zahlen von 0 bis 999 enthalten sein ... ja ? legt man dann auf dieses Feld den PK ?
Was brauch ich dann noch ?
Lg Bernie
Ups, das Problem der Arbeitstage zwischen zwei Datumswerten..... kenne ich irgendwo her.
Ich habe mich mal sehr intensiv damit beschäftigt und mir mit Hilfe aus dem I-Net eine Funktion gezimmert, die (hoffentlich auch richtig) bis zum Jahr 2199 die Anzahl der Arbeitstage zwischen 2 Datumswerten berechnen kann. (Unter Berücksichtigung der Feiertage in D.
Da kam dann aber auch die Frage, wie man wohl mit Teilzeitkräften umgeht, die anstelle von 5 Tagen die Woche nur noch 4 Tage die Woche arbeiten, bzw. wenn sie in ungeraden oder geraden Wochen einen Tag nicht arbeiten.
Das ganze ist in der anhängenden txt-Datei mal dargestellt. Ich beziehe mich bei den regelmäßigen Arbeitstagen auf ein Formular, in dem das gültige Arbeitszeitmodell dargestellt ist (sehr einfach, 10 Checkboxen für Mo-Fr in geraden und ungeraden Wochen). Das müsste dann natürlich angepasst werden.
Damit hättst Du dann aber wieder von bis Felder (Anfang und Ende des Urlaubs) Aber in das Formular ein Feld "AnzUTage" rein, darin die Funktion aufrufen und schon kannst Du die Anzahl der Urlaubstage abspeichern.............
[Anhang gelöscht durch Administrator]
Hallo,
auch ne coole Idee...
Hab jetzt die Ursprungsidee von DF6GL nochmals aufgegriffen und es so gelöst :
Hab eine Tabelle mit einem Datumswert erstellt und alle Datumswerte bis 2020 eingegeben.
Excel machts möglich.
Und nun mit diesem Code realisiert.
Zitat' Urlaubstage generieren
' *********************************************************************************************
Dim rs1 As DAO.Recordset, rs2 As DAO.Recordset, lngLfNr As Long, db As Database
Set db = CurrentDb
Set rs1 = db.OpenRecordset("Select LfdNr, Datum_Stamm From STAMM_DATUM where Datum_Stamm between " & Format(CDate(Me!Urlaubs_von_Datum), "\#yyyy-mm-dd\#") & " and " & Format(CDate(Me!Urlaubs_bis_Datum), "\#yyyy-mm-dd\#"), dbOpenSnapshot)
Set rs2 = db.OpenRecordset("Select * from STAMM_URLAUBSPLAN ", dbOpenDynaset)
Do Until rs1.EOF
For I = 1 To 1
rs2.AddNew
rs2!USER_ID = Me.USER_ID
rs2!Urlaubs_Datum = rs1!Datum_Stamm
rs2.Update
Next
rs1.MoveNext
Loop
rs2.Close: Set rs2 = Nothing
rs1.Close: Set rs1 = Nothing
Set db = Nothing
' **********************************************************************************************************
Me.U_URLAUB_ERFASSUNG_STAMM_URLAUBSPLAN_UFO.Requery
Das schöne ist, es funktioniert.... ( bitte mal drüberschauen.. ist ein umgebauter Code )
@Franz .. ist es das was du meinstest ?
@Ebs gerne würde ich aber auch noch hierzu deine Hilfe in Anspruch nehmen.
lg Bernie
Hallo,
die Anzahl Arbeitstage zu berechnen , die als Wochentage von Montag bis Freitag definiert sind, ist über die gängigen Datumsfunktionen nicht allzuschwer ...
Was Bernie aber braucht, ist eine Kalendertabelle, die JEDEN Tag eines oder auch mehrere Jahre in jeweils einem Datensatz speichert. Mit einem Status-/Kategorie-Feld werden werden die einzelnen Datum (Datensätze) als Feiertag, Arbeitstag, Brückentag, etc. näher definiert, damit spätere Berechnungen (z. B. Anzahl der wirklichen Urlaubstage) über Abfragen möglich ist und eben auch eine solche wie Ausgabe wie anfänglich dargestellt. Die T1000-Tabelle ist hier nur eine Hilfstabelle, um zur eigentlichen Kalendertabelle zu kommen. Wenn man auf die besonderen Erweiterungen der Kalendertabelle (Feiertagsangaben z. B.) verzichten kann, dann kann man schon mit der T1000-Tabelle auskommen, weil für die Berechnung der reinen Zwischentage lediglich eine laufende Nr (Inhalt der T1000) erforderlich ist.
Hallo,
"Excel machts möglich." naja, da ist halt die "Alternative" zur T1000-Tabelle mit einer Insert-Anweisung ;D ;D
Deine STAMM_DATUM - Tabelle ist m. E. halt noch nicht vollständig , weil eben die Definition von Feiertage etc., wie vorher angesprochen, nicht implementiert ist.
Zumindest ist es aber ein richtiger Zwischenschritt :D
Über die Notwendigkeit der Tabelle STAMM_URLAUBSPLAN könnte man allerdings schon noch "streiten", das hängt aber wiederum von Deinem Konzept einer solchen Kalenderverwaltung und deren gewünschter Aufgabe ab.
Hallo,
cool :)
ZitatÜber die Notwendigleit der Tabelle STAMM_URLAUBSPLAN könnte man allerdings schon noch "streiten", das hängt aber wiederum von Deinem Konzept einer solchen Kalenderverwaltung und deren gewünschter Aufgabe ab.
Ja, daran bin ich gerade. Hab eine seperate Tabelle mit Feiertagen.
Mals sehen wie ich das jetzt mache..denn diese Tabelle wird schon mehrmals für den Schichtplan benutzt.
Fragen hierzu kommen ggfs noch :)
Danke !
lg bernie
Zitat@Ebs gerne würde ich aber auch noch hierzu deine Hilfe in Anspruch nehmen.
Du drehst aber schon wieder Schleifen. Merkst Du das?
Mir wird da ganz schnell schwindelig bis schlecht, gerade bei unnötigen Schleifen.
Kannst Du erst einmal erklären,
wozu genau Du eine Tabelle benötigst, in der alle Urlaubstage einzeln drin stehen.
(Erst der Plan, dann gezielte Aktion.)
MfGA
ebs
Hallo,
im Anhang mal ein Beispiel für die Anzahl der Arbeitstage zwischen 2 Daten. Es wird eine Kalendertabelle benötigt. Der Code zur Erstellung der Kalendertabelle ist auch enthalten. Im Formular 0-... stehen Erläuterungen.
Im Beispiel sind auch Verbesserungsvorschläge (Indizierung, Wochentagszahl speichern) von Ebs17 eingearbeitet die er glaube ich mal im MOF für mein Beispiel gemacht hat.
[Anhang gelöscht durch Administrator]
Ist das nicht viel zu aufwändig? Da muss doch jedes Jahr der Kalender definiert werden.......
Wieso soll man denn jedes Jahr die Feiertage definieren, wenn ich sie bis auf 1 oder 2 für jedes Jahr berechnen kann und die übrigbleibenden dann in der Funktion festlege ? Auch festgelegte Betriebsschließungstage könnte man in die Funktion einbauen.
Selbst wenn ein Feiertag von unseren ach so geliebten Politikern nicht mehr als gesetzlich eingestuft wird, braucht man nur den Aufruf der Funktion anzupassen.
Und der Sinn, jeden Tag eines Jahres in einer Tabelle zu erfassen, will mir nicht in den Kopf.
1 Mitarbeiter * 365 Tage, ok. Sagen wir mal 400 Mitarbeiter * 365 Tage = 146.000 DS ?? Warum nur ?
Selbst wenn nur die Urlaubstage erfasst werden: 400 * (sagen wir mal) 30 Urlaubstage = 12.000 DS
Bei meiner Variante:
1 MA etwa 5 Urlaubszeiträume pro Jahr. 400 Mitarbeiter * 5 Urlaube = 2.000 DS
Kann mir jemand den Vorteil der Vorratshaltung jedes einzelnen Tages mal erklären ? Ich komme da beim besten Willen nicht hinter.
Ich will Eure Version nicht kritisieren, ich möchte sie verstehen !!!! 8)
Hallo,
dann fangen wir mal an:
ZitatDa muss doch jedes Jahr der Kalender definiert werden.......
den Kalender legst Du einmalig für die nächsten 50 Jahre an. Geht automatisch, siehe Beispiel. Es müssen dann nur die Feiertage/Arbeitsfreitage je Jahr angehakt werden, ca. 10-15 Haken je Jahr. Die Tabelle wird nur 1x benötigt,
nicht !! für jeden Mitarbeiter. Für die nächsten 50 Jahre sind das 18628 Datensätze. Das ist eine Kleinigkeit.
ZitatAuch festgelegte Betriebsschließungstage könnte man in die Funktion einbauen.
Eben, der Admin der DB muss jedes mal die Funktion anpassen. Eventuell wird auch während des Jahres noch ein arbeitsfreier Tag (Betriebsausflug) geändert/eingefügt, was zu Folge hätte dass die Funktion angepasst werden muss. Bei einer zentralen DB hätte man eine MDE, was folgendes erfordert: MDB ändern > MDE erstellen > neu verteilen. Stelle Dir jetzt mal den Aufwand vor?
Bei meiner/unserer Version => Formular aufrufen (Formular ist im Beispiel) , Haken setzen fertig. Die Datenänderungen erfolgen ausschließlich bei den Daten, nicht auf Programmierebene.
Zitat1 Mitarbeiter * 365 Tage, ok. Sagen wir mal 400 Mitarbeiter * 365 Tage = 146.000 DS ?? Warum nur ?
Das ist ohnehin ein Trugschluss, 365 DS je Jahr = wie gesagt 18628 DS für 50 Jahre. Die Mitarbeiterzahl spielt keine Rolle. Der Kalender gilt für alle.
Der Code für das Anlegen der Kalendertabelle ist auch im Beispiel, 50 Jahre dauern exakt 1,8 Sekunden.
Und dann kommt noch die Performance dazu. Um bei den 400 Mitareitern zu bleiben.
Stelle Dir vor Du willst für alle Mitarbeiter die Urlaubstage eine Jahres ermitteln:
Du musst für jeden Zeitraum und jeden Mitarbeiter über die Funktion (auch mit den Feiertagen) die Urlaubstage errechen. Und dann nach Mitarbeiter gruppieren.
Diese Abfrage rödelt noch, da bin ich mit meiner Version schon vom Mittagessen zurück. ;D ;D
Übrigens, auch professionelle Programme arbeiten mit Kalendertabellen, teilweise sogar für jeden Mitarbeiter. Z.B. die Prjektplanung von MS "Microsoft Projekt".
@69bruno:
Die Grundfrage dürfte lauten: Was ist schneller, weniger aufwändig, variabler, besser pflegbar?
1) die jedesmalige Neuberechnung oder
2) das Nachschlagen in einer Tabelle,
ob ein Datum Feiertag ist, Wochenende ist, in einem Schaltjahr liegt, in einer ungeraden DIN-Kalenderwoche liegt usw.
Zuerst wird man das bevorzugen, was man besser versteht, und da ist VBA mit seinen einfachen Befehlsabfolgen naheliegender als SQL, wo man mit Mengen umgeht. In einer Datenbank und für einen Entwickler darf das aber weniger Kriterium sein, wenn der Schwerpunkt auf einer effektiven Lösung liegt und nicht auf einem einfachen Weg hin zu einer Lösung.
Bei einer oder wenigen Berechnungen dürfte die Entscheidung ergebnisoffen sein, bei vielen oder sehr vielen Berechnungen wird dann die Nachschlagelösung die effektivere sein, um so mehr, je besser man Nachschlagen beherrscht.
Nachschlagen = optimale Abfragen auf optimale Tabellen
Natürlich ist das Vorabbereitstellen einer Kalendertabelle ein gewisser Aufwand. Mit der oben gezeigten Abfrage zeigte ich aber schon, dass eine solche Tabelle sehr zügig gefüllt werden kann. Aus einem Datum berechnete Werte wie Wochentag, DIN-Kalenderwoche, Quartal uva. kann man in der Kalendertabelle ablegen und zum Nachschlagen bereitstellen.
Und da man Feiertage berechnen kann, kann man das auch einmalig machen und diese Ergebnisse in einer Tabelle ablegen, wahlweise in der Kalendertabelle oder in einer eigenen Tabelle. Die Thematik Feiertage ist eh eine besondere, da Feiertage regional unterschiedlich sind. Im Zweifelsfall weiß ich als Entwickler (und als Bediener sowieso nicht) nicht, ob in einem bestimmten Bundesland Allerheiligen und Rosenmontag Feiertage sind oder nicht. Im Zuge der Globalisierung sollte man sogar Feiertage in anderen Ländern berücksichtigen können (Terminlieferungen!). Ich schätze mal, dann wird es sehr eckig mit reinen VBA-Funktionen und deren Aufrufen. Selbst eine Feldschmiede kann heutzutage eine Filiale in einem anderen (Bundes)Land haben. Das sollte man verwalten können.
Zusammengefasst: Die Verwendung eines einmalig berechneten Kalenders ist eine sehr praktikable Lösung. Wenn ich vor der Nase einen Tischkalender liegen habe, komme ich eher nicht auf die Idee, das Datum des nächstdritten Montags (ersatzweise Dienstag, wenn Montag Feiertag ist), im Computer zu berechnen, sondern ich schaue auf das geduldige Papier.
Ein Kalender als Tabelle ist natürlich einmalig zu berechnen und zu erstellen und nicht für jeden Mitarbeiter.
Mitarbeiterkalender erhält man über ein simples Kreuzprodukt:
SELECT K.Kalendertag, M.MitarbeiterID
FROM Kalendertabelle K, Mitarbeitertabelle M
In eine solche Abfrage kann man dann wieder ziemlich einfach individuelle Arbeitszeitmodelle einfließen lassen, die man geeignet in Tabellen festgehalten hat.
Ein weiterer Pluspunkt für eine Kalendertabelle wäre die Thematik Abfragegeschwindigkeit. Wenn ich in einer Abfrage (wie das MzKlMu in seinem Beispiel macht) einen Ausdruck YYYYMM als zusätzliches Feld berechne und danach filtere, habe ich wegen dieser Berechnung keine Indexnutzung bei der Filterung und damit verschenkte Performance.
Habe ich dieses Feld YYYYMM jedoch vorsorglich in meiner Kalendertabelle angelegt und indiziert, kann ich mir in einer beliebigen Abfrage über eine Verküpfung über den Kalendertag dieses indizierte Feld hereinholen und verwenden. Durch den nun nutzbaren Index werden trotz dieses "Umweges" Vorgänge wie Filtern, Gruppieren, Aggregieren und Sortieren auf dieses Feld deutlich schneller ablaufen können.
Also: Mit dem einmaligen Aufwand Kalendertabelle kann man sehr viel mehr Probleme lösen als das Zählen von Arbeits- oder Urlaubstagen, womit sich Aufwand relativiert.
MfGA
ebs
Hallo,
@Ebs17
Wenn ich in einer Abfrage (wie das MzKlMu in seinem Beispiel macht) einen Ausdruck YYYYMM als zusätzliches Feld berechne und danach filtere,
Diese Filterung dient ja jediglich zur Einschränkung der Daten im Formular zum einfacheren Anhaken. Und da spielt die Performance keine so große Rolle. Selbst mit den 50 Jahren ist da ein Monat innerhalb eines Augenzwinkern gefiltert.
Für die Berechnung der Urlaubstage ist das ja gar nicht notwendig.
Nur nebenbei.
Prinzipiell hast Du natürlich recht, es kann ja nur von Vorteil sein, wenn man um diese Dinge weis und auch anwendet.
@Ebs
ZitatKannst Du erst einmal erklären, wozu genau Du eine Tabelle benötigst, in der alle Urlaubstage einzeln drin stehen.
(Erst der Plan, dann gezielte Aktion.)
In meiner DB gibt es auch einen Schichtplan.
in diesem Schichtplan stehen Daten wie ... Arbeits_Beginn , Arbeits_ende..Pause usw.
In diesem Schichtplan sollen die Urlaubstage, die beantragt bzw genehmigt worden sind berücksichtigt, werden.
Ein Feld Namens "Bemerkung" besagt, ob der User im Urlaub, Krank oder Abwesend ist )
Da es im Schichtplan für jeden Tag ein eigener DS je Mitarbeiter & Datum gibt , ist es für mich und meine Accesskünste ein leichtes dies abzugleichen.
Natürlich auch wieder mit einer Schleife. ;)
Wenn man das besser machen kann..für Tipps ( die ich auch verarbeiten kann ) bin ich immer dankbar.
Gruss
Bernie
Hallo,
auch dazu ist die Kalendertabelle hilfreich. Du kannst über eine Anfügeabfrage die zwischen den Grenztagen liegenden Daten der Kalendertabelle entnehmen und anfügen.
ZitatEin Feld Namens "Bemerkung" besagt, ob der User im Urlaub, Krank oder Abwesend ist
Das würde ich nicht in das Feld Bemerkungen schreiben, sondern in ein extra Feld aber als Schlüsselzahl (1=Urlaub, 2=Krank etc.)
ZitatDiese Filterung ...
... war auch nur ein Beispiel, um kein eigenes darstellen zu müssen.
Nachdenkenswert ist der Einwurf aber auch: Kann ich im Vorfeld (bei Entwicklung) einschätzen, ob eine beschränkende Lösung (nach eigenen Kenntnissen und Erfahrungen) genügt oder sollte ich stets bestrebt sein, bei vertretbarem Aufwand das Beste zu installieren und zu verwenden?
Zuviel vorhandene Performance kann man notfalls mit ein paar Spielchen abmildern. Nachträglich Performance gewinnen zu wollen bedeutet recht oft erheblichen Aufwand. Umbau der DB?
@bernie:
Zitatim Schichtplan für jeden Tag ein eigener DS je Mitarbeiter & Datum
Das würdest Du dann benötigen, wenn Du jeden Datensatz einzeln und händisch bearbeitest, also quasi eine persönliche Anwesenheitskontrolle führst, mit Anhaken und so.
Ansonsten genügt das Festhalten von Zeiträumen (Urlaub von-bis, Krankheit von-bis, Dienstreise von-bis ...). Eine Tagestabelle erhält man dann durch einen einfachen Abgleich zwischen Kalendertabelle und Zeitraumtabelle, bspw. (vereinfacht) ...
SELECT K.Kalendertag AS Urlaubstage
FROM Kalendertabelle K, Zeitraumtabelle Z
WHERE K.Kalendertag Between Z.von AND Z.bis
AND Z.Art = 'Urlaub'MfGA
ebs
Das:
ZitatEben, der Admin der DB muss jedes mal die Funktion anpassen. Eventuell wird auch während des Jahres noch ein arbeitsfreier Tag (Betriebsausflug) geändert/eingefügt, was zu Folge hätte dass die Funktion angepasst werden muss. Bei einer zentralen DB hätte man eine MDE, was folgendes erfordert: MDB ändern > MDE erstellen > neu verteilen. Stelle Dir jetzt mal den Aufwand vor?
Bei meiner/unserer Version => Formular aufrufen (Formular ist im Beispiel) , Haken setzen fertig. Die Datenänderungen erfolgen ausschließlich bei den Daten, nicht auf Programmierebene.
ist es in meinen Augen. Ist mir nicht aufgefallen, da ich auch thematisch die DB verwalte, sprich ich bin Personaler, der nebenbei DB' bastelt, um sich arbeit zu erleichtern. Sollte ich mal weggehen, könnte das zum Problem werden :o
Die Performance wäre bei meiner Methode nicht ganz so entscheidend, weil die Funktion angestoßen wird, wenn der Zeitraum von bis eingegeben wird. dann wird ein weiteres Feld befüllt.
Jetzt muss ich mal überlegen, ob ich die DB doch änder, damit der User sie ohne Adminunterstützung auch anpassen könnte...... ;D
Danke!
@ Ebs
ZitatDas würdest Du dann benötigen, wenn Du jeden Datensatz einzeln und händisch bearbeitest, also quasi eine persönliche Anwesenheitskontrolle führst, mit Anhaken und so.
Genau um das gehts ! ;-)
Hallo,
dann passt ja auch meine vorherige Antwort.