Wie Du in einem berechneten Feld in einer Access Tabelle das Quartal eines Datums ermitteln kannst

von Philipp Stiefel, ursprünglich veröffentlicht 25.06.2015

Zuletzt aktualisiert am 26.02.2017

Kürzlich ist mir durch eine Frage in einem Access-Forum bewusst geworden, dass es in Microsoft Access ab Version 2010 die Möglichkeit gibt, berechnete Spalten in Tabellen zu erstellen. Dieses Thema erläutere ich hier umfassend. Außerdem zeige ich als Beispiel die Lösung zu dem konkreten Problem mit der Ermittlung des Quartals anhand eines Datums.

Ein berechnetes Feld erstellen

Um ein berechnetes Feld in einer Tabelle zu erstellen, kannst Du vorgehen wie folgt:

1. Öffne eine neue oder bestehende Tabelle in der Entwurfsansicht

   Wenn du eine neue Tabelle erstellt hast, solltest du sie speichern bevor du ein berechnetes Feld erstellst. Andernfalls sind die Spalten der Tabelle nicht im Ausdrucksgenerator verfügbar.

2. Gib in der Liste der Tabellenfelder den neuen, gewünschten Feldnamen ein

3. Dann wählst Du in der Spalte Felddatentyp den Type „Berechnet“ aus

   Access sollte nun automatisch den Ausdrucksgenerator öffnen. Die nächsten Schritte sind nur erforderlich falls das nicht passiert, oder du den Ausdruck später nochmal ändern möchtest.

4. In den Feldeigenschaften, im Register Allgemein klickst Du in der Zeile Ausdruck auf die drei Punkte.

5. Im Ausdrucksgenerator kannst Du mit den dort angebotenen Funktionen dann deinen Ausdruck für die Berechnung erstellen.

6. Es macht für die eigentliche Berechnung keinen Unterschied, aber dennoch empfehle ich auch den Ergebnis Typ deines Ausdrucks korrekt einzustellen.

Die Schritte 2 - 5 in Bildern:

Anstelle von Schritt 4 und 5 kannst Du natürlich auch direkt Deinen Ausdruck in das Feld schreiben. Allerdings solltest Du Folgendes dabei beachten.

Eingeschränkte Funktionsauswahl

Während in Ausdrücken in Abfragen alle Funktionen aus den eingebauten Access- und VBA-Bibliotheken, sowie eigene VBA-Funktionen verwendet werden können, ist die Auswahl der möglichen Funktionen für berechnete Spalten in Tabellen stark eingeschränkt.

Auch wenn Du den Ausdrucksgenerators in Access nicht magst, dann macht es hier durchaus Sinn, den Ausdrucksgenerator direkt aus dem berechneten Feld heraus aufzurufen und dort zu schauen, ob die jeweils benötigte Funktion dort angeboten wird. Wenn nicht, wird sie in diesem Kontext auch nicht unterstützt.

Eine generelle Einschränkung von Berechneten Feldern in Tabelle ist, dass nur Spalten aus der gleichen Tabelle in dem Berechnungsausdruck verwendet werden können.

Das Quartal eines Datums ermitteln

In dem konkreten Fall aus dem Forum wurde gefragt, wie man das Quartal eines Jahres in einem Berechneten Feld ermitteln kann. Eigentlich ist dies mit der Format-Funktion in einer Access-Abfrage eine ganz einfache Sache. Der Ausdruck dazu ist:

Allerdings ist die Format-Funktion für berechnete Spalten in Tabellen grundsätzlich nicht zulässig. In diesem Fall kannst Du das Quartal aber auch etwas umständlicher über den Monat berechnen, indem Du den Monat mit der Month-Funktion ermittelst, vom Ergebnis 1 abziehst, dann durch 3 teilst und zuletzt auf die nächst höhere Ganzzahl „aufrundest“.

Diese Berechnung in einem Ausdruck definiert sieht dann so aus:

Das „aufrundest“ steht oben in Anführungszeichen, weil es nicht ganz der eigentlichen Definition von Aufrunden entspricht. Wir erhöhen jede Zahl bis zur nächsten Ganzzahl, selbst dann wenn wir bereits eine glatte Zahl ohne Nachkommastellen als Ergebnis hatten. Die +0,51 am Ende dient dazu, die etwas eigenwillige Round-Funktion von Access/VBA immer zum Aufrunden in der o.g. Weise zu bewegen

Damit wäre das Problem, das den Ausgangspunkt zu diesem Artikel dargestellt hat, gelöst.

Berechnete Felder mit Code erstellen

Soweit mir bekannt ist, ist es nicht möglich berechnete Felder mit SQL-Anweisungen zu erstellen. Egal ob ich ein entsprechendes ALTER TABLE für eine solche Spalte mit DAO oder mit ADO ausgeführt habe, es kam immer eine „Syntax Error in Feld Definition“-Meldung.

Es ist allerdings möglich ein berechnetes Feld mit VBA und dem DAO.TableDef-Objekt zu erstellen. Dies ist absolut unkompliziert machbar und unterscheidet sich nicht viel davon eine Spalte mit irgendeinem anderen Datentyp zu erstellen. Du musst lediglich deinen Berechnungsausdruck der Expression-Eigenschaft des erstellten DAO.Field-Objektes zuweisen.

Hier ist eine Beispielprozedur, die ein berechnetes Feld analog zu den oben gezeigten, manuellen Schritten erstellt.

Es scheint allerdings nicht möglich zu sein, die Definition eines solchen berechneten Feldes nochmal per VBA-Code zu ändern, nachdem es an die Fields-Auflistung des TableDef-Objektes angefügt wurde. - Da aber die Daten für die Berechnung sowieso zwingend in anderen Spalten der Tabelle gespeichert sind, ist es ein sehr einfacher Workaround, einfach das bestehende Feld zu löschen und ein neues Feld mit der geänderten Definition zu erstellen.

Performance von berechneten Feldern

Es ist nicht einfach in der offiziellen Access Dokumentation eine verbindliche Aussage dazu zu finden, aber aus meinen eigenen Versuchen dazu geht sehr deutlich hervor, dass Access die Ergebnisse der Berechnungen eines berechneten Tabellenfeldes tatsächlich in der jeweiligen Tabelle abspeichert, anstatt sie bei jeder Anzeige der Ergebnisse neu zu berechnen.

Leider ist es in Access (getestet mit 2010 und 2013), anders als z.B. beim Microsoft SQL Server, nicht möglich ist, die Werte der berechneten Felder zu indizieren. Daher kann man mit berechneten Tabellenfeldern nur eine verschwindend geringe Performanceverbesserung gegenüber Berechnungen in Abfragen erzielen.

Um dir einen Eindruck von den Auswirkungen zu geben, habe ich einen groben Performancevergleich zwischen berechneten Spalten in Abfragen und in Tabellen durchgeführt.

Der Vollständigkeit halber kommt hier noch ein Chart der die Ergebnisse visualisiert:

Der Unterschied sieht auf den ersten Blick riesig aus, aber bitte beachte, dass dieser Performancevergleich sehr konstruiert ist.

2 Millionen Datensätze in einer Access-Tabelle sind eine Menge. Ich habe zwar in echten Anwendungen durchaus so große Tabellen gesehen, aber sie sind schon sehr selten.

Eine Berechnung basierend auf Tabellendaten in den Kriterien einer Abfrage zu verwenden sollte möglichst vermieden werden. Wenn deine Anwendung sehr davon abhängig ist, große Datenmengen im Wesentlichen mit berechneten Feldern im Kriterium zu filtern, deutet das auf einen Fehler in deinem Datenmodell hin.

In normalen Szenarios sollte der Performanceunterschied zwischen einer Berechnung in einer Tabelle und einer Berechnung in einer Abfrage praktisch kaum messbar sein.

Also ist das Fazit hier, dass es zwar einen winzigen Performancevorteil durch Berechnungen in Tabellen geben könnte, aber wenn dieser echte Relevanz in deiner Applikation hat, dann gibt es sehr wahrscheinlich andere Optionen zur Performanceoptimierung, die wesentlich wirkungsvoller sind.

Probleme mit berechneten Feldern

Beachte bitte unbedingt, dass berechnete Felder in Tabellen erst ab Access 2010 möglich sind. Eine Tabelle, die berechnete Felder enthält, kann in älteren Versionen von Access nicht geöffnet werden!

Es gibt einige Quellen im Internet die davor warnen, dass die Daten, die in einer berechneten Spalte gespeichert wurden, nicht neu berechnet werden, wenn der zugrundeliegende Berechnungsausdruck der Spalte geändert wird. - Mir ist es aber nicht gelungen, dieses Problem mit Access 2010 oder 2013 mit aktuellem Patchlevel zu reproduzieren.

Grundsätzliches zu berechneten Feldern

Bedenke bitte immer, dass, anders als in Excel, Tabellen in relationalen Datenbanken eigentlich nicht dazu vorgesehen sind, um Werte zu berechnen, sondern nur um Daten zu speichern.

Aus meiner Sicht ist es eine gute Vorgehensweise die Anwendungslogik von den gespeicherten Daten strukturell abzugrenzen. Wenn du Anwendungslogik, wie z.B. Berechnungen, nur in höheren Ebenen deiner Anwendung, also Abfragen und Code unterbringst und die Tabellen nur die reinen Daten enthalten, ist die Trennung zwischen persistenten Daten und berechneten Ergebnissen wesentliche klarer.

Dennoch möchte ich zwei Szenarien nennen, in denen berechnete Felder in einer Tabelle eventuell Sinn machen könnten.

1. Wenn das berechnete Feld derartig zentrale Bedeutung innerhalb der Tabelle hat, das man davon ausgehen kann, dass dieses Feld immer und überall angezeigt werden soll, wenn Daten aus der Tabelle dargestellt werden.
2. Wenn man eine „offene Anwendung“ erstellt, in der auch Erweiterungen durch Benutzer zulässig oder sogar erwünscht sind. In diesem Fall hat es Vorteile, wenn man die Logik der berechneten Felder überall automatisch zur Verfügung stellen kann, ohne den Benutzer die Trennung zwischen Daten (Tabelle) und Logik (Abfrage) erläutern zu müssen.

Ich persönlich würde dennoch in beiden Fällen die klassische Lösung mit einer reinen Datentabelle und einer darüber liegenden Abfrage zur Berechnung vorziehen. Diese bedeutet zwar in beiden Fällen etwas mehr Aufwand, aber den nehme ich für die klarere Strukturierung der Anwendung gerne in Kauf.

Begleitvideo

Hier ist ein begleitendes Video, das ich zu diesem Artikel aufgenommen habe.

Wenn dir das Video gefällt, dann klick bitte den „Gefällt mir“-Daumen auf YouTube. - Danke!

Weitere Informationen

Zum Abschluss möchte ich noch auf einen sehr guten, allerdings englischen,Artikel zu berechneten Feldern von Ken Getz im Office Dev Center hinweisen.

Share this article: