Eval-Funktion

[hanskuhn]

ebs17: Das ist schon ein konkretes Anliegen von mir: Ich möchte halt, dass die Werte aus meiner Spalte "Wert" nutzerabhängig verrechnet werden. Ich weiss nicht, ob eine Abfrage effektiver ist - sicher nicht so aufwendig, klar. Aber wie bekomme ich sowas in eine Abfrage rein? Die müsste ich dann dynamisch zur Laufzeit zusammensetzen oder wie soll das funktionieren?!

Meine Ausgangstabelle ist, wie gesagt, folgende:

ID|Wert|Kürzel|Verrechnungregel
1|1234|A|A
2|2345|B|A+B
3|543|C|(A+B)-C
etc...

Mein Anliegen ist nun, die Verrechnung anhand der Spalte "Verrechnungsregel" durchzuführen, indem ich die "Kürzel" durch die Werte aus der Spalte "Wert" des betreffenden Datensatzes ersetze.

DF6GL schrieb es schon:
bei ID=3   ID1Wert + ID2Wert -ID3Wert   (---> (1234+ 2345) -543)  )

[ebs17]

Franz schrieb auch:

aber warum steht dann bei JEDEM Datensatz eine extra Regel?.  Den Zusammenhang versteh ich noch nicht. M. E gehören die Rechnenregeln in eine extra Tabelle, aus den man eine bestimmte Regel auswählt und dann auf die Werte in der Werte-Tabelle anwendet.

Etwas mehr musst Du einen solchen Fall schon erläutern. Solch eine Tabelle nimmt man im Normalfall nicht kritiklos entgegen.
Mir ist bisher nur ein Fall untergekommen, wo Formeln sinnvoll in Tabellen abgelegt und diese Tabelleneinträge für Berechnungen herangezogen wurden. Dabei handelte es sich um Aufmassberechnungen, wo Flächen und Volumen von geometrischen Körpern zu ermitteln waren, wobei der Nutzer allerdings keine Formeln eingegeben hat, sondern "nur" den jeweiligen geometrischen Körper ausgewählt hat.

Momentan hat Deine Tabelle eine deutliche Ähnlichkeit zu einer Exceltabelle (Werte und Formeln vereinigt). Eine solche gegenseitige Abhängigkeit der Datensätze in einer Datenbanktabelle untereinander habe ich noch gar nicht gesehen. Das ist weit ab von üblichen Regeln (die sich an Erfahrungen orientieren).
Es macht wenig Sinn, Excel in Access nachzubauen.

Um wiederum datenbankmäßig, also mit Abfragen zu arbeiten, ist eine entsprechende Datenmodellierung unabdingbar.

MfGA
ebs

[hanskuhn]

Ok, also folgendes Szenario:

Bei der Tabelle handelt es sich ja um Zähler und deren Werte. Allerdings sind das eine Unterzähler von anderen Zählern etc., d.h. die abgelesenen Werte müssen u.U. noch miteinander verrechnet werden. Die Spalte Wert enthält also den Ablesewert und die Spalte Verrechnungsregel gibt halt an, wie der letztendliche Wert zustande kommt. Da alle anderen Berechnungen wieder in Abfragen stehen, ist es auch sinnvoll, das in Access zu belassen.
Wie sollte eine neue Datenmodellierung etwas an dem Umstand ändern, dass userabhängig etwas berechnet werden soll

[DF6GL]

Hallo,

"Wie sollte eine neue Datenmodellierung etwas an dem Umstand ändern, dass userabhängig etwas berechnet werden soll"


es würde das Wörtchen "soll" in "kann" ändern... 

[hanskuhn]

Also gut, ich habe meine Methode jetzt mal weiter verfolgt, da ich nicht sehe, wie ich durch eine Neustrukturierung meiner Tabellen das Grundproblem lösen kann. Die Eval-Funktion arbeitet bei mir, wenn ich die Anführungszeichen komplett weg lasse. Ich weiß auch nicht, warum ich die Eval-Funktion nicht verwenden sollte, wenn sie in Access zur Verfügung steht?!
Es macht für mich ja wenig Sinn, meine Formeln in eine Extra-Tabelle zu packen, wenn jeder Datensatz ohnehin eine individuelle Berechnung, also 1:1-Beziehung, zugewiesen bekommt.

[ebs17]

Soll man aus Deinem vorletzten Beitrag schließen, dass ein User ein Zähler ist?

Um Verbräuche an Hand von Zählerständen zu ermitteln, muss man einfach nur addieren, eine passende Tabellenstruktur vorausgesetzt, und das geht mit SQL prima und rasant und deutlich einfacher als mit dem oben gezeigten Code-"Ungetüm" aus Recordset und Domänenaggregatfunktionen.

Was womit zu summieren wäre, ergibt sich aus Zuordnungen wie Nutzer - Zähler und Hauptzähler - Unterzähler.

Ich weiß auch nicht, warum ich die Eval-Funktion nicht verwenden sollte, wenn sie in Access zur Verfügung steht?!

Vermutlich reden wir aneinander vorbei: Meine Fragen/Vorschläge gehen in die Richtung, die Anwendung an sich besser zu gestalten, eben in Richtung Datenbankanwendung. Dass man da i.d.R. Eval nicht benötigt, ist nur ein Nebeneffekt.

Wenn Du natürlich alles und in Deiner Art ausprobieren und verwenden möchtest, was Dir Access zur Verfügung stellt, so ist das Dein gutes Recht. Dafür wünsche ich viel Erfolg.

MfGA
ebs

[hanskuhn]

Hm, natürlich könnte ich das auch alles in getrennte Tabellen packen und miteinander verrechnen. Allerdings sind die Beziehungen zueinander doch recht komplex und da ich eh nur eine Handvoll Zähler habe, lohnt es sich imho nicht, da jetzt noch mehrere Tabellen anzuhängen. Deshalb halte ich diesen Weg, auch wenn ein wenig unkonventionell, in diesem Fall für gangbar.
Also, danke für eure Anmerkungen!

[Bitsqueezer]

Hallo,

ich würde mich zwar auch der Meinung anschließen, daß es hier etwas Tabellenkonzeptarbeit notwendig ist, aber prinzipiell läßt sich das Problem auch einfach mit SQL lösen (mit vielen VBA-Funktionen, versteht sich):

Zuerst eine simple Abfrage, die den Wert für jedes Kürzel ermittelt:

Code (vb) [Auswählen] Erweitern

SELECT tblZaehler.Kürzel, tblZaehler.Wert
  FROM tblZaehler;

und dann kann man mit diesem "kleinen" Konstrukt (hier für die drei genannten Kürzel, wenn mehr benötigt werden, muß die Abfrage entsprechend erweitert werden) die Berechnung von SQL erledigen lassen:

Code (vb) [Auswählen] Erweitern

SELECT ID, Wert, Kürzel, Verrechnungsregel,
   Eval(Replace(Replace(Replace(Verrechnungsregel,"A",
(SELECT TOP 1 qryKürzelWert.Wert FROM qryKürzelWert
  WHERE qryKürzelWert.Kürzel="A")
),"B",
(SELECT TOP 1 qryKürzelWert.Wert FROM qryKürzelWert
  WHERE qryKürzelWert.Kürzel="B")
),"C",
(SELECT TOP 1 qryKürzelWert.Wert FROM qryKürzelWert
  WHERE qryKürzelWert.Kürzel="C")
)
) AS Ergebnis
FROM tblZaehler;

(Wobei "tblZaehler" dann gegen den entsprechenden Abfragenamen zu ersetzen wäre.)

Gruß

Christian

[ebs17]

@Christian: Das ist ein schöner systematischer Ansatz, wonach man auch die SQL-Anweisung per VBA erweitern kann.

Allerdings ist das auch ein mutiger Ansatz. Von drei Datensätzen auf eine Tabelle unbekannter Größe und unbekannten Inhalts in Folge zu schließen halte ich, insbesondere wegen der bisherigen Heransgehensweise des TE, für recht gewagt.
Ob dann die SQL-Anweisung für die Realtabelle einfach bleibt ... ?

MfGA
ebs

[Bitsqueezer]

Hallo,

naja, wie gesagt, es ist nur eine Möglichkeit, und nur darum gewählt, weil der Autor gesagt hat, es seien nur "eine Handvoll" Werte, so daß man das gerade noch so verwenden kann.

Gruß

Christian