Fehler bei Berechnung

[Beaker s.a.]

@Ratoncito
Der Aufbau der tblBewegung(en) ist m.E. falsch. Du hast zwei Felder mit im
Prinzip gleichem Inhalt, die entweder/oder einen Wert bekommen. Die sind
also typisiert, wie man auch an den beiden "nur" in der Feldbeschreibung
ablesen kann. Es reicht ein Feld für "Kurs_NennWert" und ein Feld für den
"AssetTyp". Somit gibt es nur noch ein Feld für Berechnungen einzelner Titel
oder Assetklassen.
gruss ekkehard

[MzKlMu]

Hallo,
warum hast Du in der letzten Abfrage den Bestand als berechnetes feld zugewiesen:

Code [Auswählen] Erweitern

Bestand: Bestand
Hier in der Abfrage Euro als Format einzustellen ist sinnlos. Eine Formatzuweisung hat mit dem Datentyp nichts zu tun.

Ansonsten:

Wenn Du nicht weiter kommst, erstelle ein kleines Beispiel,

[Ratoncito]

Hallo,

@Beaker s.a.
Vermutlich hast Du recht. Das ist eine komplizierte Frage, deren Auswirkung ich nicht bis zum Ende abschätzen kann.
Grund für die Trennung war, dass Anleihen zu einem Nennwert, Aktien und Fonds in Stück gehandelt werden. Wobei Nennwert bzw. Stück eine Mengenangabe sind und auch Bruchstücke enthalten können. Also Dezimalzahlen.
Die Kurse (Tageskurse) für Anleihen werden im Gegensatz zu Aktien oder Fonds in % angegeben.
Daher hatte ich für Stück und Nennwert ein eigenes Feld vorgesehen.

Bei den ganzen Überlegungen hierzu ist mir folgendes aufgefallen.

Die Abfragen für den Bestand habe ich für die Berechnung und Anzeige des Wertes auf einem Formular benötigt. Daher hatte ich den Nennwert / 100 für den Bestand gerechnet um anschließend im Formular bei Kurs * Bestand keine Unterscheidung zwischen Anleihen und Fonds bzw. Aktien machen zu müssen.

Eine Kopie dieser Abfrage habe ich auch für rptRendite (allerdings mit anderen Kriterien für Datum verwendet). In dieser Abfrage habe ich jetzt die Formel
Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert]/100)+Nz([Stueck]);Nz(0-([Nennwert]/100))+Nz(0-[Stueck]))
in
Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert])+Nz([Stueck]);Nz(0-([Nennwert]))-Nz([Stueck]))
gändert.

Nun werden alle Bestände korrekt angezeigt.

@MzKlMu
In der qryBestandRendite wird die Summe vom Bestand aus der Abfrage qryBewegungRendite gebildet, da in einem Feld mit einer Formel wohl die Summenbildung nicht möglich ist. Zumindest habe ich es nicht hinbekommen.

In der Abfrage hatte ich als Format Währung eingestellt. Ich hatte dies durchgängig in allen beteiligten Feldern gemacht, um ganz sicher zu gehen. Ist mittlerweile als Standardzahl formatiert und ist okay.


Ganz allgemein möchte ich nochmal bemerken, dass meine Kenntnisse nicht ausreichen um die DB von Anfang bis Ende komplett strukturiert zu planen.
Zuerst habe ich mich bei den Formularen von einem Problem zum nächsten gehangelt. Ich habe immer wieder neue Ansätze verfolgt um zum Ziel zu kommen, und sicherlich nicht die elegansten Lösungen gefunden.
Nun geht es mir bei den Auswertungen auch nicht anders.

LG - Wolfgang

[MzKlMu]

Hallol,

In der Abfrage hatte ich als Format Währung eingestellt.

Um es noch mal ganz deutlich zu sagen:
Ein in den Eigenschaften eingestelltest Format ist völlig bedeutungslos. Das hat mit dem eigentlichen Datentyp des Feldes nichts zu tun. Da kannst Du auch Kg einstellen oder Liter oder was auch immer.
Das ändert nichts am Rechenergebnis bzw. am Verhalten des Datentyps und dem in der Tabelle gespeicherten Wert.
Für die Rechengenauigkeit ist ausschließlich der in der Tabelle angelegte Datentyp zuständig.
Oder die Werte werden explizit in den entsprechenden Datentyp gewandelt wie in #15 beschrieben.

[Beaker s.a.]

@Ratoncito

Die Kurse (Tageskurse) für Anleihen werden im Gegensatz zu Aktien oder Fonds in % angegeben.

Spielt doch keine Rolle, %-Werte lassen sich auch durch den Datentyp
"Währung" darstellen. Zur Anzeige kann das anhand der Assetklasse
entsprechend formatiert werden.
gruss ekkehard

[MzKlMu]

Hallo,
auch für % ist Währung geeignet, zumal das % Format eine gewisse Tücke hat, in der Tabelle steht dann nämlich für die angezeigten 10% 0,1 was immer wider zu Problemen führen kann.

[Ratoncito]

Hallo,

@Beaker s.a.
Den Hinweis auf die Felder für Stück und Nennwert in der tblBewegung muss ich mal bis zum Ende verfolgen. Eine Änderung hat Einfluss auf viele Abfragen und Formulare. Sollte aber meine Abfragen vereinfachen. Da werde ich mich über Ostern mit beschäftigen.


In der qryBewegungRendite ist im Feld Bestand die Formel:
Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert]/100)+Nz([Stueck]);Nz(0-([Nennwert]/100))-Nz([Stueck]))

Wenn ich diese ändere:
Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert])+Nz([Stueck]);Nz(0-([Nennwert]))-Nz([Stueck]))

funktioniert die Abfrage auf "0" korrekt.

Gibt es dafür eine Erklärung?

LG - Wolfgang

[Beaker s.a.]

Hallo Klaus,

Code [Auswählen] Erweitern

in der Tabelle steht dann nämlich für die angezeigten 10% 0,1 was immer wider zu Problemen führen kann.
Aber nur wenn man mit Prozentrechnung nicht klar kommt  . Was ich dir
aber hiermit keinesfalls unterstellen möchte, also nicht falsch verstehen.
In die Tabelle gehört doch auch nichts anderes als 0,1 (Datentyp "Währung").
Das entspricht 1/10 bzw. 10%. Und nur damit rechne ich auch.
Und, wie gesagt, anzeigen, sprich formatieren kann ich den Wert wie ich will.
gruss ekkehard

[Ratoncito]

Hallo,

darf ich nochmal hierauf zurück kommen?

In der qryBewegungRendite ist im Feld Bestand die Formel:
Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert]/100)+Nz([Stueck]);Nz(0-([Nennwert]/100))-Nz([Stueck]))

Wenn ich diese ändere:
Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert])+Nz([Stueck]);Nz(0-([Nennwert]))-Nz([Stueck]))

funktioniert die Abfrage auf "0" korrekt.

Gibt es dafür eine Erklärung?

Ich habe den Hinweis von
@Beaker s.a.
umgesetzt und die Felder Nennwert und Stueck in einem Feld zusammengefasst.

Daher hat sich auch die Abfrage geändert und das Problem tritt gar nicht erst auf.

Trotzdem würde mich schon eine Erklärung interessieren warum es durch " /100 " und der späteren Abfrage auf " =0 " zu einem falschen Ergebnis kommt.

LG und schöne Ostern - Wolfgang

[DF6GL]

Hallo,

die Erklärung hast Du doch nun schon 1000 Mal erhalten!


Der "/" Operator (Division durch)  hat als Ergebnis eine Gleitkommazahl (oder Fließkommazahl --> googlen!). Diese Zahl muss mathematisch nicht genau 0,00000000000000000000   ergeben, sondern kann auch 0,00000000000000001   sein und hängt auch von der internen "Zahlenauflösung", sprich Binärsystem des Rechners ab.

(auch Beispiel:  100/3  = 33,33333333333333333333333... )


Und 0,00000000000000001 ist eben nicht genau 0 (---> 0,0000000000000000000000000000000)

Um einen Vergleich mit genau 0  zu realisieren, muss entweder gerundet 
oder ein "Nicht-Gleitkomma-Datentyp" (---> "Währung") gewählt
oder ein Vergleich mit einem passenden Zahlen-Bereich eingesetzt werden.  (  between <0.001 and > -0.001  ) .

Klarer jetzt?


Du kannst Dich ja auch mal selber etwas schlauer machen, wenn Du die Unterschiede der einzelnen Datentypen (nicht Formate!)  mal "studierst":

https://docs.microsoft.com/de-de/office/vba/language/reference/user-interface-help/currency-data-type

[Ratoncito]

Hallo,

die Erklärung hast Du doch nun schon 1000 Mal erhalten!

Sorry, das stimmt so nicht. Dass das Problem durch eine Gleit- oder Fließkommazahl verursacht wird habe ich verstanden. Allerdings sollte es, wie beschrieben, durch eine Änderung des Datentyps auf Währung in der Tabelle erledigt sein.

Für die Rechengenauigkeit ist ausschließlich der in der Tabelle angelegte Datentyp zuständig.

Ich bin überzeugt davon, wenn alle beteiligten Felder (völlig unabhängig vom Inhalt) auf Währung umgestellt werden, ist das Problem erledigt.

Das ist so nicht der Fall, daher habe ich um eine Erklärung gebeten, warum bei einer Division in der Formel der Abfrage eine spätere Abfrage auf " =0 " zu einem falschen Ergebnis führt.

Du kannst Dich ja auch mal selber etwas schlauer machen, wenn Du die Unterschiede der einzelnen Datentypen (nicht Formate!)  mal "studierst":

Die Auflistung der unterschiedlichen Datentypen liefert leider keine Erklärung warum man, wie oben beschrieben, ein falsches Egebnis erhält.

LG - Wolfgang

[MzKlMu]

Hallo,
wie von Franz gesagt:

Der "/" Operator (Division durch)  hat als Ergebnis eine Gleitkommazahl (oder Fließkommazahl ....

Mit anderen Worten, die Division macht aus der Währung wieder eine Gleitkommazahl, wodurch Du wieder das Problem hast.
Du musst nach der Division mit CCur() wieder explizit in Währung umwandeln wie in #15 beschrieben.
Die Anwendung von Nz in Deiner Formel kann so auch nicht sinnvoll sein.
Mit Nz wird aus NULL (=Nix) ein Wert erzeugt.
Das Nz([Nennwert]/100) kann niemals NULL sein, also ist hier Nz zwecklos. Außerdem ist kein Ersatzwert angegeben der bei NULL angewendet werden soll.

Warum setzt Du hier Nz ein ?
Kann der Nennwert und/oder Stück NULL sein ?

ein falsches Ergebnis erhält.

Irgendwie drehen wir uns im Kreis. Das ist nicht falsch. Das ist das im Rahmen der Auflösung/Genauigkeit des Datentyps Fließkommazahl richtige Ergebnis. Das musst Du auf Deine Anforderungen anpassen, entweder durch runden, Konvertierungen oder einen Bereichsvergleich  (between +0.001 and  -0.001).
 

[ebs17]

Um das zusammenzufassen (Wiederholungen kann man haben, wenn man das Thema selber von vorn nach hinten liest und dabei eigenverwendete Filter mal abschaltet):

Fehler bei Berechnung entpuppt sich als Fehler in der individuellen Betrachtung und als Nichtverwendung geeigneter Mittel. Auf das Fremdwort RUNDEN ist dem TE noch kein Feedback gelungen.

[DF6GL]

Hallo,

Sorry, das stimmt so nicht.

Ja, da hast Du Recht.  Es sind soviel:

X = 1/0,001000000001

[Ratoncito]

Hallo,

Der "/" Operator (Division durch)  hat als Ergebnis eine Gleitkommazahl (oder Fließkommazahl ....

Mit anderen Worten, die Division macht aus der Währung wieder eine Gleitkommazahl, wodurch Du wieder das Problem hast.
Du musst nach der Division mit CCur() wieder explizit in Währung umwandeln wie in #15 beschrieben.
Die Anwendung von Nz in Deiner Formel kann so auch nicht sinnvoll sein.
Mit Nz wird aus NULL (=Nix) ein Wert erzeugt.
Das Nz([Nennwert]/100) kann niemals NULL sein, also ist hier Nz zwecklos. Außerdem ist kein Ersatzwert angegeben der bei NULL angewendet werden soll.

Warum setzt Du hier Nz ein ?
Kann der Nennwert und/oder Stück NULL sein ?

Sorry, wenn es hier so rüberkommt als würde ich nicht alles lesen oder einiges nicht beachten.
Es wurde mehrmals geschrieben, dass es lediglich auf den Datentyp der zugrundeliegenden Tabelle ankommt.
Moniert wurde, das ich in allen beteiligten Feldern das Format auf Währung gesetzt hatte, obwohl ich geschrieben hatte, dass ich das gemacht habe, um ganz sicher zu gehen, als es in den Feldern mit Standardzahl nicht funktioniert hat.

In #15 steht:
? CCur(70) - CCur(58.66) - CCur(11.34) = 0
Auch in einer Abfrage auf Tabellenfelder vom Typ Currency mit den von dir genannten Werten ist das Ergebnis exakt 0.

Was soll mir das sagen, was muss ich wo eintragen?

Für Euch als Experten versteht ihr sicherlich, was gemeint ist. Ich zerbreche mir den Kopf und komm zu keinem Ergebnis.
Auch wenn es nicht mehr aktuell nötig ist (durch den Hinweis von Baker s.a und der Änderung der tblBewegung hat sich die Formel erübrigt), hätte ich gerne gewusst, wo und wie CCur eingesetzt werden sollte.

Das Nz hatte ich verwendet, weil leere Felder einen Fehler in der Wenn-Formel verursachten. Ich glaube, dass ich das auch schon mal geschrieben hatte. Ganz nachvollziehen kann ich es leider nicht mehr.

Auch wenn es nicht zu jedem Ansatz (Runden) ein Feedback gibt, darüber nachgedacht habe ich schon, wollte dies aber als letzte Möglichkeit in Betracht ziehen.

Nochmals
Vielen Dank an Alle, die hier geantwortet haben.
Access ist sicherlich sehr umfangreich und hat viele Überraschungen und Stolpersteine parat, über die Ihr als Experten gar nicht mehr nachdenkt, aber mir und anderen Anfängern immer wieder Probleme bereiten.

LG - Wolfgang