Fehler bei Berechnung

[PhilS]

Obwohl in allen beteiligten Feldern der Datentyp auf Währung eingestelltist, führt eine Abfrage mit "=0" zu einem falschen Ergebnis.

Es muss doch möglich sein, einfache mathematische Berechnungen mit einem eindeutigen Ergebnis auszuführen, und im Ergebnis auf "0" abzufragen. In diesem Fall 70 - 58,66 - 11,34 = 0

Das kann ich so nicht bestätigen.

Im Direktfenster:

Code [Auswählen] Erweitern

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

[DF6GL]

Hallo,

der Datentyp "Währung" hat zunächst mal nichts mit einer Finanz-Währung zu tun.
Datentyp "Währung" in Access ist lediglich eine Ganzzahl, die eine definierte Anzahl von Nachkommastellen hat. Solche Zahlen werden wie normale Ganzzahlen behandelt, bei denen lediglich (intern) das Dezimalzeichen mathematisch korrekt positioniert wird.



Der Name "Währung" kommt daher, dass man im Finanzbereich Rundungen soweit wie möglich vermeiden wollte und sich dabei zu einer Festkomma-Zahl mit festen 4 Nachkommastellen entschieden hat. Die Berechnungen mit 1/10000stel Dollar (0,0001), Euro oder sonstwas erscheinen genau genug zu sein.

Dass in Access bei Datentyp "Währung" ein Geldwährungsname ("Euro") erscheint, ist von den Windows-Ländereinstellungen abhängig und der Userfreundlichkeit von Access zu verdanken.

https://support.office.com/de-de/article/datentypen-f%C3%BCr-access-desktopdatenbanken-df2b83ba-cef6-436d-b679-3418f622e482

bei Nennwert nicht um eine Währung

Die Aussage beruht auf falscher Annahme.  Siehe oben.

Was ist der "Nennwert" denn dann?  Eine Ganzzahl (wie 1 oder 2123 oder 99)  oder eine Dezimalzahl (mit Stellen nach dem Komma wie 1,5  oder 2123,57 oder 99,155)?


Wobei die Frage eher rhetorischer Art ist, denn alle Beispiel-Zahlen sind mit Datentyp "Währung" abdeckbar.

...führt eine Abfrage mit "=0"

Dann zeig mal den (kompletten) SQL-String einer solchen Abfrage..

... Where (Feld1 - Feld2 - Feld3) = 0

[ebs17]

@Phil:
Bei Addition und Subtraktion würde ich auch nicht wirklich Probleme bzgl. Fließkommazahl erwarten, bei verwendeten Divisionen dann schon.

Soweit mir bewusst ist, vergibt Jet bei berechneten Feldern selber erst mal den Datentyp, und der ist einfach bei Zahlen mit Dezimalstellen Double. Eine Auswahlmöglichkeit dazu wäre mir nicht bekannt. Man könnte nachträglich konvertieren, aber Kaufleuten ist auch die Methode Runden bekannt, schon länger als es Computer gibt.

1,02140518265514E-14

Wenn man das auf zwei Nachkommastellen rundet: Was kommt da wohl heraus?

werden Berechnungen durchgeführt

Dazu aber auch eine Bemerkung:

Code [Auswählen] Erweitern

Nz(0-([Nennwert]/100))
Wenn ich so etwas sehe, dann läuten bei mir gleich mehrere Glocken. Einen eventuell vorhandenen Azubi würde ich mit so etwas nicht in den Feierabend entlassen.
Rechnen (an sich) und sinnhaft direkt Rechnen können recht unterschiedliche Dinge sein.

[PhilS]

@Phil:
Bei Addition und Subtraktion würde ich auch nicht wirklich Probleme bzgl. Fließkommazahl erwarten, [...]

Das hätte ich ursprünglich auch nicht, aber das Beispiel von @Ratoncito war schon gut gewählt:

Code [Auswählen] Erweitern

? 70 - 58.66 - 11.34
3,5527136788005E-15

[Ratoncito]

Hallo,

vielen Dank für die ausführlichen Antworten. Ich versuche mal alles ein wenig aufzubröseln und die Fragen zu beantworten.

Zuerst möchte ich mal bemerken, dass Access beim Speichern das Format bzw. den Felddatentyp ändert. Auswahl "Währung" in "Euro".

der Datentyp "Währung" hat zunächst mal nichts mit einer Finanz-Währung zu tun.
Datentyp "Währung" in Access ist lediglich eine Ganzzahl, die eine definierte Anzahl von Nachkommastellen hat. Solche Zahlen werden wie normale Ganzzahlen behandelt, bei denen lediglich (intern) das Dezimalzeichen mathematisch korrekt positioniert wird.

Danke, habe ich jetzt verstanden, obwohl ich es lästig finde, dass ständig das €-Zeichen erscheint, obwohl es da nicht hingehört.

bei Nennwert nicht um eine Währung

Die Aussage beruht auf falscher Annahme.  Siehe oben.

Was ist der "Nennwert" denn dann?  Eine Ganzzahl (wie 1 oder 2123 oder 99)  oder eine Dezimalzahl (mit Stellen nach dem Komma wie 1,5  oder 2123,57 oder 99,155)?

Der Nennwert ist eine Menge, Bestand, Stück. Wie z.Bsp. eine Anzahl Obst, dabei ist es egal ob Äpfel, Birnen oder Bananen.
Es ist eine Dezimalzahl, bei der ich mit 4 Nachkommastellen auskomme.

Code [Auswählen] Erweitern

Nz(0-([Nennwert]/100))
Wenn ich so etwas sehe, dann läuten bei mir gleich mehrere Glocken. Einen eventuell vorhandenen Azubi würde ich mit so etwas nicht in den Feierabend entlassen.
Rechnen (an sich) und sinnhaft direkt Rechnen können recht unterschiedliche Dinge sein.

Der Azubi ist hier  und hat schon mehrfach um Hilfe gerufen.
Bei der Ermittlung des Bestands habe ich allergrößte Probleme und bekomme es leider nur auf diese umständliche Weise gelöst.

Die zu ermittelnden Werte sind in folgenden Tabellen: tblKonto, tblBewegung und tblWePa.

Die erste Abfrage ist: qryBewegungRendite
Darin ist auch die Formel
Art = 4
Es ist ein Kauf, andernfalls ein Verkauf
Für die Berechnung benötige ich den Bestand (Nennwert/100 oder Stück), bei einem Verkauf entsprechend als Minus.

Code (sql) [Auswählen] Erweitern

SELECT tblWePa.Num, tblWePa.WPKN, tblKonto.DatumKonto, IIf([tblKonto]![Art]=4,Nz([Nennwert]/100)+Nz([Stueck]),Nz(0-([Nennwert]/100))+Nz(0-[Stueck])) AS Bestand, tblWePa.Art, tblWePa.ID
FROM tblWePa INNER JOIN (tblKonto INNER JOIN tblBewegung ON tblKonto.ID = tblBewegung.IdfKonto) ON tblWePa.ID = tblBewegung.IdfWePa
ORDER BY tblWePa.Num, tblKonto.DatumKonto;


Daraus die Ermittlung des Bestands: qryBestandRendite

Code (sql) [Auswählen] Erweitern

SELECT qryBewegungRendite.Num, qryBewegungRendite.WPKN, Sum(qryBewegungRendite.Bestand) AS Bestand, tblWePa.ID, tblWePa.Bezeichnung, tblWePa.Isin
FROM qryBewegungRendite INNER JOIN tblWePa ON qryBewegungRendite.WPKN = tblWePa.WPKN
GROUP BY qryBewegungRendite.Num, qryBewegungRendite.WPKN, tblWePa.ID, tblWePa.Bezeichnung, tblWePa.Isin
HAVING (((Sum(qryBewegungRendite.Bestand))=0))
ORDER BY qryBewegungRendite.Num;


Hieraus qryRepRendite

Code (sql) [Auswählen] Erweitern

SELECT qryBestandRendite.ID, qryBestandRendite.Bezeichnung, tblKonto.DatumKonto, IIf([tblKonto]![Art]=4,0-[tblKonto]![Betrag],IIf([tblKonto]![Art]>4,[tblKonto]![Betrag],0)) AS Betrag
FROM (tblWePa INNER JOIN qryBestandRendite ON tblWePa.ID = qryBestandRendite.ID) INNER JOIN (tblKonto INNER JOIN tblBewegung ON tblKonto.ID = tblBewegung.IdfKonto) ON tblWePa.ID = tblBewegung.IdfWePa
ORDER BY qryBestandRendite.ID, tblKonto.DatumKonto;


und

Code (sql) [Auswählen] Erweitern

TRANSFORM Sum(qryRepRendite.Betrag) AS SummevonBetrag
SELECT qryRepRendite.ID, qryRepRendite.Bezeichnung, Sum(qryRepRendite.Betrag) AS [Gesamtsumme von Betrag]
FROM qryRepRendite
GROUP BY qryRepRendite.ID, qryRepRendite.Bezeichnung
ORDER BY qryRepRendite.ID
PIVOT Format([DatumKonto],"yyyy");


Wie schon beschrieben wird ein Wertpapier nicht aufgeführt, obwohl in der tblBewegung der Wert für den Kauf 7.000,00 € und für die Verkäufe 5.866,47 € und 1.133,53 € sind.

Im Voraus schon mal vielen Dank für Eure Mühe.

LG - Wolfgang

[MzKlMu]

Hallo,

dass Access beim Speichern das Format bzw. den Felddatentyp ändert. Auswahl "Währung" in "Euro".

Das ist so nicht richtig. Es wird nicht der Datentyp geändert, es wird das Format auf EURO eingestellt. Wenn Du dann anschließend das Format auf "Festkommazahl" oder "Standardzahl" (mit Angabe der Kommastellen max 4) umstellst, ist das EURO Zeichen dauerhaft weg. Mit dem Datentyp hat das nichts zu tun.

Das hatte ich so ähnlich schon in #13 geschrieben.

[DF6GL]

Hallo,

Der Nennwert ist eine Menge, Bestand, Stück. Wie z.Bsp. eine Anzahl Obst, dabei ist es egal ob Äpfel, Birnen oder Bananen.
Es ist eine Dezimalzahl, bei der ich mit 4 Nachkommastellen auskomme.

Überleg mal, was Du da schreibst...

Einen "Menge" und ein "Bestand" kann eine rationale Zahl sein (1,2 ; 23,95; 5 ; 99)  und dafür wäre ein Single, Double oder Währung-Datentyp einsetzbar.
Bei "Stück" kann es sich nur um eine Ganzzahl handeln.  Es gibt nicht "3,1 Stück". Somit ist hier der Datentyp Long (Integer) am Besten geeignet (wenn nicht der Wertebereich des Datentyps zu beachten ist).

Das Format-(Währungs-)zeichen "€" bei Datentyp Währung kann in den Tabelleneigenschaften oder auch den Formular-Steuerelement-Eigenschaften umgestellt oder entfernt werden. Dort ist es nur als Vorgabewert eingestellt.

Die NZ-Funktion ist völlig falsch eingesetzt. Die NZ-Funktion liefert einen (anzugebenden) Ersatzwert nur bei Datentyp Variant  (alle leeren Tabellenfelder und leeren Steuerelement haben den Datentyp Variant) zurück.

Ein Ansetzen auf einen Berechnungs-Ausdruck ist sinnlos und hat keinen Effekt. (das wollte ebs ausdrücken)

Nz(0-([Nennwert]/100))   --->   - nz([Nennwert],0)/100

Hier wird nz auf das Feld "Nennwert" angewendet und liefert bei leerem Feld den numerischen Wert 0  zurück. Dieser Wert wird durch 100 geteilt, so dass das Ergebnis eine reelle Zahl (Kommazahl) ergibt. Standardmäßig wird diese Zahl in Datentyp Double konvertiert.

Will man nun den Währungs-Datentyp benutzen (wegen Rundungsproblemen) , ist die explizite Konvertierung mit CCur() anzusetzen, wenn man wie in Abfragen nicht den Wert einer Variablen mit Datentyp "Währung" zuweisen kann:

- CCur(nz([Nennwert],0)/100) 

(hat Phil ja schon angedeutet)

Vielleicht wird die Sache  endlich klar...

[Beaker s.a.]

Hallo Franz,

Bei "Stück" kann es sich nur um eine Ganzzahl handeln.  Es gibt nicht "3,1 Stück".

Das stimmt leider in diesem Zusammenhang nicht. Fonds und Kryptowährung
z.B. werden auch in Teilstücken gehandelt.
gruss ekkehard

[DF6GL]

Hallo,

na gut, ist dann wohl sehr speziell. 

"Units" wäre auch besser mit "Anteile" als denn mit "Stück" zu übersetzen.


Trotzdem wäre "Stück" sinngemäß eher bei "Einheit" denn als "Betrag" oder "Menge" anzusiedeln.

[Ratoncito]

Hallo,

Die NZ-Funktion ist völlig falsch eingesetzt. Die NZ-Funktion liefert einen (anzugebenden) Ersatzwert nur bei Datentyp Variant  (alle leeren Tabellenfelder und leeren Steuerelement haben den Datentyp Variant) zurück.

Ein Ansetzen auf einen Berechnungs-Ausdruck ist sinnlos und hat keinen Effekt. (das wollte ebs ausdrücken)

Nz(0-([Nennwert]/100))   --->   - nz([Nennwert],0)/100

Hier wird nz auf das Feld "Nennwert" angewendet und liefert bei leerem Feld den numerischen Wert 0  zurück. Dieser Wert wird durch 100 geteilt, so dass das Ergebnis eine reelle Zahl (Kommazahl) ergibt. Standardmäßig wird diese Zahl in Datentyp Double konvertiert.

Ich habe die Formel abgeändert.

Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert]/100)+Nz([Stueck]);- nz([Nennwert],0)/100 - Nz[Stueck])

Das Problem besteht immer noch.

Ich finde es schade, dass die Lösung eines Problems zur Nebensache wird, und es mehr um Namen und Bezeichnungen geht.
Dass Stück in der eigentlichen Bedeutung nicht teilbar ist, steht nicht zur Debatte und ist sicherlich jedem bekannt.
Fonds, Aktien und Anleihen werden oft in Bruchteilen gehandelt und mit Stück, Anteil oder Nennwert bezeichnet, auch wenn es genau betrachtet nicht korrekt ist. Für mich ist die Bezeichnung Stück und Nennwert zur Unterscheidung wichtig und akzeptabel und der Nennwert ist keine Währung. Es wäre schön, wenn man das so akzeptieren würde.

Ich habe schon oft geschrieben, dass ich kein Access-Experte bin, und würde mich über Hilfe bei der Lösung meines Problems freuen.

LG - Wolfgang

[MzKlMu]

Hallo,
es ist für jemand der keine Ahnung hat von der Materie schwer Deinen Ausführungen zu folgen.
Es gab hier schon viele Hinweise zur Lösung das Problems. Du gehst auch nicht weiter auf die Hinweise ein.  Z.B. in #20 Entfernung des Eurozeichens.
Ich bin überzeugt davon, wenn alle beteiligten Felder (völlig unabhängig vom Inhalt) auf Währung umgestellt werden, ist das Problem erledigt.
Ggf. müssen Zwischenergebnisse noch in Währung konvertiert werden wie in #15 beschrieben.

Das Ganze ist keine Access Problem, das hängt nur mit der Fließkommaproblematik zusammen.
Ich kann mich erinnern, als es so 1971/72 die ersten Taschenrechner gab, war 0 auch nicht immer 0.

Wenn Du nicht weiter kommst, erstelle ein kleines Beispiel, das ganau die Problematik zeigt und das Problem ist schnell gelöst.

[DF6GL]

Hallo,

Ich habe die Formel abgeändert.

Die Änderung der Formel zeigt, dass Du noch nichts von dem verstanden hast, was man Dir bislang erklärt hat...

[ebs17]

Bei der Ermittlung des Bestands habe ich allergrößte Probleme und bekomme es leider nur auf diese umständliche Weise gelöst.

Ich selber würde eine Lösung auf einem durchdacht guten und mir bekanntem Datenmodell, ggf. unterlegt mit einigen repräsentativen Daten, aufbauen. In Tabellen mit Daten wären Felddatentypen und Indizes bereits eingepreist.

Eine bloße Nennung von Tabellen und einige Anweisungen, die per Selbsteinschätzung umständlich sind, sind mir zur Erfassung von Sinn und Ablauf regelmäßig zu anstrengend. Mir ist auch meine Zeit wertvoll.

und würde mich über Hilfe bei der Lösung meines Problems freuen

Dein Problem sind Dezimalanteile aus Fließkommazahlrechnungen, egal, ob Du diese beherrschst oder nicht, ob Du sie verstehst oder nicht, ob Du sie akzeptierst oder nicht.

Im Text wurde auch der Hinweis Runden gemacht. Den könnte man auch wahrnehmen, und Runden machen viele, auch jene , die nicht mal wissen, was Access ist. Das ist also nichts Extra-Spezifisches.

Ein Runden wird schon eintreten, wenn man einfach das Berechnungsergebnis in der Anzeige auf zwei oder vier Dezimalstellen begrenzt. Das könnte schon ausreichen.
Daneben gibt es Funktionen explizit zum Runden, wo man in diesem Vorgang definieren kann, wann genau ein Wert gerundet wird (wegen Folgerechnung und -vergleich), wieviele Dezimalstellen, Rundungstechnik (kaufmännisch oder anders).

In Wiederholung:

Code [Auswählen] Erweitern

1,02140518265514E-14
Wenn man das auf zwei Nachkommastellen rundet: Was kommt da wohl heraus?
Runden

[DF6GL]

OT:

1,02140518265514E-14
Wenn man das auf zwei Nachkommastellen rundet: Was kommt da wohl heraus?

<Milchmädchenrechnung>

natürlich 1,02  was denn sonst?

</Milchmädchenrechnung>

LOL

[Ratoncito]

Hallo,

Obwohl in allen beteiligten Feldern der Datentyp auf Währung eingestellt ist, führt eine Abfrage mit "=0" zu einem falschen Ergebnis.

Die Tabelle und Abfragen sind im Anhang. Ich habe überall Währung bzw. Euro stehen gelassen, um nichts falsch zu machen.
Die SQL-Codes zu allen Abfragen habe ich schon gepostet.

Wenn ich da irgendwo etwas falsch mache, dann sagt mir bitte wo und was, und wie es richtig sein muss.

LG - Wolfgang