Access-o-Mania

Hi,
ich habe eine Prozedur, die mir zu Tabellen berechnete Felder hinzufügt. Klappt soweit ganz gut, außer der Formelausdruck enthält ein Komma, weil z.B. das erstellte Feld den Wert eines anderen Feldes mit 0,3 multiplizieren soll. Dann steht im Formelausdruck nicht 0,3*Summe sondern 0;3*Summe
Woran kann das liegen?
Sub BerechnetesFeldHinzufuegen(TabellenName As String, FeldName As String, Datentyp As DAO.DataTypeEnum, Berechnungsformel As String)

    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Dim fld As DAO.Field

    Set db = CurrentDb
    Set tdf = db.TableDefs(TabellenName)
    Set fld = tdf.CreateField(FeldName, Datentyp)
    [color=red]fld.Expression = Berechnungsformel[/color]

    tdf.Fields.Append fld

    db.TableDefs.Refresh

    Set fld = Nothing
    Set tdf = Nothing
    Set db = Nothing

    MsgBox "Das berechnete Feld '" & FeldName & "' wurde erfolgreich hinzugefügt."
End Sub


Hallo,
das Wichtigste, die eigentliche Berechnung zeigst du nicht.
In VBA muß zwingend als Dezimaltrenner der Punkt verwendet werden.

Aber, das Vorhaben ist überflüssig, denn in einer Datenbank werden berechnete Werte nicht gespeichert, sondern in einer Abfrage nur bei Bedarf berechnet.

Verrückterweise bietet MS ja seit einigen Versionen an, dass man in einem Tabellenentwurf zu einem Feld den Datentyp ,,Berechnet" festlegen kann,
was aber, so denke ich, vom regulären DB-Standard abweicht und für die meisten von uns ,,Bää" ist. Auch habe ich festgestellt, dass hier nicht alles geht (weiß nicht mehr genau, was geht und was nicht, in meiner Erinnerung verwehrt Access zu recht komplexen Formeln den Dienst).

Aber viele Neueinsteiger, die ggf. aus der Excel-Welt kommen, fahren offenbar darauf ab.
Wie Klaus schon andeutete, sind Berechnungen eigentlich immer in Berechneten Feldern in Abfragen umzusetzen.
Peter, Du solltest es so machen wie Klaus vorschlug.

Es sind viele verschiedene Berechnungen, deshalb hab ich mir ja diese Prozedur zugelegt...

Es gibt doch in Access 2016 den Datentyp "berechnetes Feld", spricht irgendwas dagegen, ihn zu verwenden? Vermutlich wird er intern gar nicht groß anders als eine Berechnung in einer Abfrage gehandelt, oder? Also kann man doch, statt für eine Tabelle, zur der man ein berechnetes Feld braucht, eine zusätzliche Abfrage zu erstellen, genauso gut dieses berechnete Tabellenfeld erstellen?

Hallo,

ZitatEs sind viele verschiedene Berechnungen, deshalb hab ich mir ja diese Prozedur zugelegt...

Die Prozedur kann auch in Abfragen verwendet werden.

Zitatgenauso gut dieses berechnete Tabellenfeld erstellen?

Nein, die berechneten Tabellenfelder haben Einschränkungen, so können z.B. nur Felder verwendet werden die in der Tabelle selbst vorkommen, auch funktionieren nicht alle Berechnungsfunktionen. So kann z.B. Dllokup nicht verwendet werden. Auch die Aggregatfunktionen (Summieren, Zählen, Mittelwert usw.). Und, berechnete Felder werden immer berechnet, egal, ob das gerade benötigt wird oder nicht. Was ggf. die ePerformance einschränkt.
Daher ist die Berechnung in Abfragen immer zu bevorzugen.

Hallo,

um mal wieder die Lanze zu brechen FÜR berechnete Felder:

Dies ist auch in professionellen Datenbanken wie SQL Server gang und gäbe, auch wenn man dort einiges mehr damit machen kann (wie persistente Speicherung und Indizierung etwa).

Es ist absolut sinnvoll, berechnete Felder zu verwenden, wenn man Dinge aus anderen Feldern zusammenfassen will.

• In einer Bestellpositionen-Tabelle KANN "Wert * Menge" sinnvoll sein, solange die Berechnung keine komplexeren Abhängigkeiten wie spezielle Rabatte etc. benötigt.
• In einer Namenstabelle ist es sehr sinnvoll, Name und Vorname zusammenzusetzen, um immer ein einheitliches Format zu garantieren und nicht mit jeder Abfrage neu zu definieren.
• Allen Browne sagt (A2010), die Felder würden die falschen Ergebnisse liefern, wenn man den Ausdruck nachträglich ändert, die bestehenden Werte würden nicht neu berechnet - in A2013 gerade getestet, ist natürlich Unsinn, denn wenn dem so wäre, würden die Ergebnisse ja nur beim Speichern eines Datensatzes berechnet und dann gespeichert. Wäre dem so, dann wären sie ja auch in Access indizierbar. Nein, eine Änderung der Formel zeigt die Ergebnisse auch dann korrekt an.
• Performance beim Öffnen: In Access kann man nur Felder des gleichen Datensatzes der gleichen Tabelle einbeziehen. Das ist daher nicht schneller oder langsamer, als eine Berechnung in eine Abfrage einzufügen.
• Das Argument, was man oft hört, "wenn man die Tabelle öffnet, wird immer berechnet, auch wenn man es gar nicht braucht!" - ja, und wer arbeitet denn direkt in Tabellen, das machen wir braven Programmierer doch nie. Wir predigen immer: Erstelle Abfragen, schließe nur die Felder ein, die Du brauchst, arbeite mit Formularen auf diesen Abfragen. Und wenn man es so macht, muß man ein berechnetes Feld nicht mit einbauen, wenn man es nicht benötigt.
• Andere Argumente wie bei Allen Browne: Wir führen Redundanz ein - das ist genauso Unsinn. Es werden in Access ja nicht einmal die Ergebnisse gespeichert, es ist also nur eine Live-Berechnung und damit 0 Redundanz.
• Wie oben beschrieben: Beim Zusammensetzen von Namen oder z.B. bestimmter Formate wie ein Aktenzeichen, das aus mehreren Feldern gebildet werden soll usw. ist es extrem hilfreich, solche Felder zu verwenden, weil man diese in einer Abfrage dann einfach über ihren Namen einschließen kann und man muß nicht in jeder Abfrage, die das braucht, die Formel erneut (und vielleicht falsch) einbauen. Wenn man es mal ändern muß, ändert man die Formel an einer Stelle und alle Abfragen können davon profitieren, ohne einzeln geändert zu werden.
• Bitte nicht eine Abfrage erstellen, die die Berechnung enthält, und diese dann als Basis für andere zu verwenden, um die Berechnung einheitlich zu haben. Ist die Berechnung in der Tabelle selbst als berechnetes Feld, kann jede Abfrage alle Indizes der Tabelle, die existieren, verwenden. Eine Abfrage auf eine Abfrage kann dazu führen, daß diese nicht mehr verwendet werden und entsprechend langsamer ist.

Also: Kommt mal weg von dem Gedanken, daß berechnete Felder in Tabellen etwas Schlechtes sind, sind sie nicht und wird auch in professionellen Datenbanken eingesetzt. Wer als Backend von Access mal wegkommt und SQL Server o.Ä. einsetzt, wird sich insbesondere über die Persistenz- und Indexmöglichkeit freuen, mit denen man noch eine ganze Menge mehr aus den Datenbanken herausholen kann.

Ich betone allerdings, daß ich nicht die Datenmakros in Access meine. Makros sind ja so schon die Seuche, aber auf Tabellenebene - geht gar nicht.

Gruß

Christian

Zitat von: MzKlMu am Januar 16, 2025, 11:33:07Und, berechnete Felder werden immer berechnet, egal, ob das gerade benötigt wird oder nicht. Was ggf. die ePerformance einschränkt.
Daher ist die Berechnung in Abfragen immer zu bevorzugen.

Bei einer Abfrage werden doch auch die Berechnungen für alle berechneten Felder durchgeführt? Kann da keinen Unterschied erkennen.

Für mich macht es die Sache übersichtlicher. Die Tabelle mit einem berechneten Feld ist letztlich sowas wie eine Abfrage auf diese Tabelle, bloß dass ich kein zusätzliches Objekt in der Datenbank brauche

Hallo,
ich beziehe ja einen Großteil von dem was ich empfehle oder propagiere aus dem was ich im Laufe der Jahrzehnte aus den Foren und sonstigen Quellen zu Access gelesen habe. Das was ich bisher zu diesen berechneten Feldern gelesen habe, habe ich oben wiedergegeben. Das bedeutet aber auch, dass man aus weiteren Beiträgen immer weiter lernt. Offensichtlich muss ich nun meine Meinung über dies Felder nach dem Vortrag von Christian ändern (seufz).  :)

Zitat von: MzKlMu am Januar 16, 2025, 15:37:31Offensichtlich muss ich nun meine Meinung über dies Felder nach dem Vortrag von Christian ändern (seufz).  :)

Ich schließe mich dann mal dem Seufz vom Klaus an und ziehe meine Aussage in #2 zurück.

[OT]

Hallo!

ZitatIch betone allerdings, daß ich nicht die Datenmakros in Access meine. Makros sind ja so schon die Seuche, aber auf Tabellenebene - geht gar nicht.

.. außer man betrachtet diese Datenmarkos wie Trigger, dann könnten sie schon etwas bringen, wenn man unbedingt ein File-Backend wie Access einsetzen will/muss. (Ich muss zum Glück nicht. ;))
Z. B. zum Protokollieren von Änderungen in eine "Änderungsprotokoll"-Tabelle.
Anm.: das Schreiben von diesen "Triggern" ist aber gewöhnungsbedürftig (um es freundlich auszudrücken) ;)

ZitatBitte nicht eine Abfrage erstellen, die die Berechnung enthält, und diese dann als Basis für andere zu verwenden, um die Berechnung einheitlich zu haben. Ist die Berechnung in der Tabelle selbst als berechnetes Feld, kann jede Abfrage alle Indizes der Tabelle, die existieren, verwenden. Eine Abfrage auf eine Abfrage kann dazu führen, daß diese nicht mehr verwendet werden und entsprechend langsamer ist.

Unter welchen Umständen (außer bei der Verwendung von distinct und eventuell group by) kommt das vor, dass der Index nicht genutzt wird, solange die Abfrage grundsätzlich index-freundlich gestaltet ist?
Hab mittlerweile zu wenig Praxix mit Jet/ACE.
Der SQL-Server würde
select
   a, b, c
from (
   select
      a, b, a+b as c
   from
      Tabelle
   where
      b = 1
   ) as X
where
   a = 5auflösen und als ein einziges select-Statement interpretieren und einen verfügbaren 2-Felder-Index über a + b nutzen.

LG
Josef

Hallo Josef,

habe gerade ein paar Tests auf dem SQL Server mit meiner MNIST-Variante gemacht, die rd. 1,6Mio Datensätze hat (bei zu wenig Datensätzen verwendet SQL Server einfach einen Tablescan) - Du hast recht.
Der Optimizer von SQL Server setzt die Abfragen vor der Ausführung zusammen und optimiert dann, was man alles zusammenfassen kann und wo welcher Index am besten genutzt werden kann.
Dabei spielt es auch keine Rolle, ob es eine Unterabfrage, eine CTE oder eine gespeicherte View (der Unterabfrage) ist.
Der Optimizer von SQL Server ist allerdings auch extrem gut, ob das in gleichem Maß für eine Access-Abfrage gilt, müßte man überprüfen (aber man kommt nur schwer an die internen Daten bei einer Abfrage, was mir persönlich immer zu umständlich ist).

Also da wir alle gerade beim Zurücknehmen sind, nehme ich den Punkt mit der Abfrage auf die Abfrage zurück. Dennoch würde ich eher ein berechnetes Feld als eine Abfrage dafür verwenden, die ja immer zusätzlich zur Tabelle abgefragt werden muß, wohingehend bei einem berechneten Feld ich nur mit der einen Tabelle arbeiten kann.

Gruß

Christian