Office: (Office 2016) Rechnen im Formular

Hallo,
ich habe ein Endlosformular mit 31 Felder(Kalendertage), diese stammen aus einer Tabelle/Abfrage. In den Feldern werden Buchstabenkürzel eingetragen die für einen Anwesenheits.- oder Abwesenheitsgrund stehen. Neben diesen Feldern möchte ich nun die Eintragungen in mehrern Felder zählen(siehe Bild1) rechts, z.B ein "A" das für Anwesend steht. Dafür habe ich in dem Feld eine Formel eingetragen (siehe Bild2). Wenn ich mehr wie zwei Kriterien eintrage akzeptiert das Access, wergen Überschreiten der Argumente, nicht. Klar ich kann für jedes Kriterium ein eigenes Feld verwenden und anschließend wieder in einem weiteren mehrere zusammenrechnen.
Weil das, dass Hauptbearbeitungsformular ist, möchte ich auf diese zusammengerechnete Übersicht nicht verzichten.
Was ich im Formular zähle und anzeige wird auch noch in einer Aktualisierungsabfrage gemacht, diese schreibt die Werte dann in die Tabelle.
Welche Möglichkeit gibt es noch, leider ist mir diesbezüglich nichts mehr eingefallen. Könnte man das auch mit einer Funktion realiesieren?

:)

 

Inwieweit hast Du Dich den GRUNDLAGEN einer Datenbank schon einmal angenähert? 31 Felder mit gleichem Inhalt haben damit nicht sehr viel zu tun, Berechnungsergebnisse daraus zusätzlich in weiteren Datensatzfeldern zu speichern, auch nicht.
So etwas, was Du da führst in dieser Form, wäre etwas für Excel.

Eine andere Tabellenstruktur (Speicherstruktur) ändert aber sehr viel hinsichtlich Hauptbearbeitung, Zusammenzählen, Darstellung des Ganzen usw.

 

Von der Grundstruktur möchte ich mich nicht mehr trennen, die Datenbank läuf auf einem Server und die Programversionen sind auf max. 10 Personen verteilt.
Wir dokumentieren damit halt die Anwesenheit u. Abwesenheit für ca. 180 Mitarbeiter. Es werden auch Bericht erstellt die monatlich für die Weitergabe in anderer Form der Daten sehr hilfreich sind. Die Anwendung funktionier und die Bearbeitung übers Netz ist halt bischen lahm, geht aber noch. Mit Excel hatten wir vorher gearbeitet, da taten sich ganz andere Probleme auf, aus diesem Grund versuchen wir es nun mit Access um nur noch einen Datenbestand zu haben.
Danke:
Wenn noch einer eine Ide hat um die Berechnung zu vereinfachen, für weitere Beiträge bin ich sehr Dankbar.
Willi

 

Deine Probleme resultieren im Wesentlichen aus dem unbrauchbaren Datenmodell. Solange Du das nicht ändern willst, musst Du halt mit den Konsequenzen leben. Basta. (Frei nach G. Schröder...)

Gruß
Fred

 

Über alles: Hoffentlich kommt keiner auf die Idee, da noch mehr Funktionalität hineinpacken und sich zusätzliche Wünsche erfüllen zu wollen. Zum Querlesen: Sonstiges - Es war einmal eine kleine Exceltabelle ...

 

Was meinst du damit?

 

Hallo,

Wenn Du mit Access arbeiten willst, musst Du Dich von dieser Grundstruktur trennen, ohne Wenn und Aber. Das wird so nix.
Wer in einer Datenbank solche Wenn Orgien braucht hat was falsch gemacht.
Access erlaubt ca. 5-7 verschachtelte Wenn, dann ist ohnehin Schluss.
In einer normalsierten Tabellenstruktur wirst Du eine solche Auswertung ohne eine einzige Formel machen können.
Und eine Aktualisierungsabfrage braucht es da auch nicht, denn berechnete Werte werden in einer Datenbank nicht gespeichert.

Daher stammt wahrscheinlich auch die für Access ungeeignete Tabellenstruktur.

Erkläre mal den Aufbau dieser Tabelle.

 

Die Tabelle besteht halt aus den Spalten
Name, Bereich, Jahr, Monat und den Tagen 1-31 alle als Text formatiert

Wenn ich ja alles Falsch gemacht habe, wie muss man den an die Sache ran gehen?
Willi

 

Hallo,
ganz einfach Du brauchst eine Tabelle mit einem Datum, ein Feld für den Fremdschlüssel zur Person, einem Feld für Zeitart (ebenfalls als Fremdschlüssel)

Also so:

Code:

Teitarten:
1=Anwesend
2=Urlaub
3=Krank

Kannst Du naürlich festlegen wie Du willst.

Die Summierung der Zeitarten efolgt dann gann einfach mit einer Abfrage die über die Person und Zeitart gruppiert wird. Eine Formel braucht es da nicht.

Was ist der bereich, da wo die Person arbeitet ?

 

\@Klaus
Aus Sicht des Datenmodells ist das, was Du aufzeigst, natürlich der richtige Weg.
Wie aber soll er daraus sein "Hauptbearbeitungsformular" speisen, so wie man
es im Screenshot sehen kann? *Smilie

 

Hi, ich grätsch mal rein:
Ein solches Formular wie Du oben gepostet hast, habe ich auf massiven Wunsch eines Kunden hin mal gebaut (ging um eine Einsatzplanung). Mit einer sauberen Datenbankstruktur dahinter ist das nur mit x Umwegen und massivem VBA-Einsatz machbar.

Wesentlicher besser (einfacher): bau die DB so auf wie oben vorgeschlagen. Die Erfassung der Daten erfolgt dann in einem Haupt-/Unterformular. Die Tage werden dann nicht in der Horizontalen sondern in der Vertikalen abgebildet.

 

Alles hat seinen Grund, bevor ich angefangen habe, habe ich mir schon Gedanken über Horizentral oder Vertikal gemacht. Klar, einfacher zum rechnen ist Vertikal.
Aber die Optik, mit bedingten Formatierungen Farbumschlag bei Feiertagen, Samstag und Sonntagen ist einfach bedienerfreundlicher und übersichtiger.
Die Daten werden max für zwei Jahre vorgehalten und wenn dann Stamdateneintragungen fehlen ist das auch nicht so schön. Die Vorgesetzen der einzelenen Bereiche sollen die Möglichkeit haben mit einer optische Ansicht die Personalstärke zu bewerten.
VBA Prorgamierung ist da schon einiges drin.

Vieleicht geht auch einiges einfacher und ich habe es verkompliziert, aber es funktioniert alles. Da ich kein Profi bin, hatte ich gehofft ggf. noch eine praktikabele Idee zu erhalten.

Ich bedanke mich bei allen die sich meiner Sache angenommen haben.
Danke.
Willi

 

Hallo,
eine relationale Datenbank wird im Regelfall Vertikal aufgebaut.
Alle Aggregatfunktionen bassieren auf vertikalem Aufbau.

Aus diesem Aufbau laasen sich dann mit mehr oder wenig großem Aufwand fast beliebige Ansichten erzeugen.
Ob sich jetzt die von Dir gewünschte Darstellung dann so realisieren lässt wird man dann sehen.
Aber möglicherweise ergeben sich ja durch einen normalisierten Aufbau ganz andere (einfacher anzulegende) Ansichten und Auswertungen, dass die besser ist als die jetzige.
Ich würde also die DB mit normalisierter Struktur aufbauen und dann die Auswertungen und Ansichten darum anlegen.

Mit Deinem jetzigen Aufbau kann sich offenbar keiner so recht anfreunden, da das nicht einer Datenbankstruktur entspricht hat da auch niemand eine Lösung parat. Zum Testen müsste man das nachbauen, was aber niemand so recht will, weil man es ja eigntlich gar nicht braucht.

Du wirst hier also mit recht wenig Hilfe zu Deinem aktuellen Problem rechnen können.

 

Hallo coladadelsid,

Wenn sichergestellt ist, dass die jeweils getrennt zu summierenden Buchstabenkürzel jeweils unterschiedliche Buchstaben enthalten, dann könnte die Anzahl auch über die Textlänge ermittelt werden ( z. B. für "A" und "AT" zusammen …… = Textlänge aller [1] bis [31] abzüglich Textlänge aller [1] bis [31] mit entferntem "A"):

 

Du meinst er soll erstmal alles umstellen um dann zu sehen, dass es das Problem bleibt. *grins *grins

@coladadelsid,
das Hauptproblem: Access hat ein Problem, mit dem was du machen willst.
Entweder du erfasst die Daten m:n und musst per Pivot darstellen und kannst die Daten nur mit hohem Aufwand in der Pivot Darstellung bearbeiten.

Oder man macht es so wie du es jetzt machst.
Um die Summen zu bilden machst du ein einfaches unpivot.
Das kann Access aber nicht. Musst einfach eine entsprechende Abfrage erstellen und dann kannst du wie gewohnt mittels SQL arbeiten.

Wenn du bei der Abfrage Hilfe brauchst, einfach mal das Datenmodell der Tabelle zeigen.

Alles kein Hexenwerk.
Was am Ende des Tages besser oder einfacher ist, kann man so nicht sagen.
Man kann es jedenfalls mit beiden Modellen umsetzen. *wink.gif*

Edit:
Man sollte sich aber Bewusst sein, dass deinem Modell weit mehr Grenzen gesetzt sind wie der m:n Darstellung und
das Anpassungen in diesem Modell weit mehr Aufwand bedeutet.
Stell dir vor du brauchst für jeden Tag noch ein zusätzliches Feld oder mehrere Einträge pro Tag.
Dann wird es lustig und man geht ganz schnell wieder zu m:n zurück.
Die Schwierigkeit ist aber, dass man künftige Anpassungen nicht voraussehen kann.
Ich meine also, man sollte zumindest in der Lage sein beide Modell umzusetzen.