Access-o-Mania

Hallo,

in einer Tabelle habe ich ein Feld
Felddatentyp: Zahl
Feldgröße: Double
Format: Standardzahl
Dezimalstellenanzeige: Automatisch

In der Tabelle sind in 7 Feldern Werte eingetragen, von denen 2 jeweils 2 Nachkommastellen haben, alle anderen Felder sind 0.

In einer Abfrage werden Berechnungen durchgeführt. Rein mathematisch ist das Ergebnis 0, allerdings enthält das Feld den Wert
1,02140518265514E-14

In allen Feldern ist das Format Standardzahl eingetragen.

In einer Abfrage gibt es bei der Berechnung eine Formel:

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

Hat jemand eine Erklärung?

LG - Wolfgang

Hallo,
das ist kein Fehler, sondern normal. Das ist das typische Problem einer Fließkommazahl.

https://de.wikipedia.org/wiki/Gleitkommazahl.

1,02140518265514E-14 entspricht 0,0000000000000002140518265514 also (fast) 0.


Verwende statt Double den Datentyp Währung.

Hallo,

danke für die Antwort, aber ist Währung richtig? Es handelt sich um Stück, bzw. um eine normale Zahl.

Bei allen Berechnungen die in diesem Fall gemacht werden, können eigentlich nur Werte mit 2 Nachkommastellen vorkommen. Daher verstehe ich nicht wo dieser extrem kleine Rest herkommen soll.

LG - Wolfgang

Hallo,

ZitatDaher verstehe ich nicht wo dieser extrem kleine Rest herkommen soll.

Ließ den Artikel den ich verlinkt habe, dann weißt Du es. Das ist völlig normal, das hat auch nichts mit Access zu tun, das ist Mathematik. Das hat jedes Programm das mit Fließkomma rechnet und dein Taschenrechner. Auch Excel, nur nimmt man da eine höhere Genauigkeit (8 oder 16 bit).
Du kannst völlig problemlos Währung nehmen, musst nur das Währungszeichen entfernen.
Währung rechnet mit Ganzzahlen (macht die Komma erst weg und fügt diese beim Ergebnis wieder hinzu).

Und mir scheint, Währung passt auch, oder ist der Nennwert keine Währung ?

Guten Morgen,

Zitat von: Ratoncito am März 19, 2020, 17:59:59

danke für die Antwort, aber ist Währung richtig? Es handelt sich um Stück, bzw. um eine normale Zahl.

Es ist das erste Mal, dass mir so etwas passiert. In der Tabelle gibt es noch zig andere Berechnungen, die alle korrekt angezeigt werden. Über Fließkommazahlen hatte ich schon mal etwas gelesen.

Ich bin davon ausgegangen, dass solche kleinen Reste dann vorkommen können, wenn es im Laufe der Berechnung ein Ergebnis gibt, bei dem die Nachkommastellen nicht ausreichen (z.Bsp. 1/3). Das ist hier nicht der Fall.

LG - Wolfgang

Hallo,

ZitatEs ist das erste Mal, dass mir so etwas passiert.

Dann hast Du Glück gehabt oder es nicht bemerkt. Wenn Du diese Zahl 1,02140518265514E-14 als Standardzahl mit 2 Kommastellen formatierst, wird 0,00 angezeigt.
Und den Rest schleppst Du als Rundungsfehler mit. Der sich bei vielen Datensätzen summieren kann und zu Problemen führt. Beim Datentyp Single (wo viele meinen das reicht) wird das Problem noch größer.
Daher ist es unerlässlich sobald eine Währung ins Spiel kommt auch Währung als Datentyp zu verwenden.
Und der Nennwert ist doch Währung, oder nicht (hatte ich schon mal gefragt) ?

Um es noch mal zu sagen, das ist kein Access Problem, das ist reine Mathematik und das Problem hat jedes Programm das Fließkommazahlen verwendet.
Das ist systembedingt und ist kein Fehler.

Hallo Klaus,

vielen Dank für Deine Antwort.

Ich hatte es schon 2 mal geschrieben, dass es sich um Stück, bzw. eine normale Zahl handelt.  :)

Es ist keine Währung!

In der Zwischenzeit habe ich mir die Tabelle bzw. die Abfragen nochmal genauer angesehen. Es gibt noch weitere Felder mit ähnlichen Problemen. Ich bin erst darauf aufmerksam geworden, als ich eine Abfrage mit >0 ausgeführt habe und dort ein Feld mit diesem kleinen Rest für ein überaschendes Ergebnis führte.

Im Moment habe ich mir damit geholfen, dass ich die Abfrage auf >0,00000001 geändert habe. Hilft mir im Moment weiter, ist aber sicherlich nicht korrekt.

Wie geht man korrekt mit diesem Problem um?

LG - Wolfgang

Hallo,
ich fragte nach dem Nennwert. Und der Nennwert kommt doch in Deiner Formel vor.
Und das ist doch Währung, oder nicht ?

ZitatWie geht man korrekt mit diesem Problem um?

Wie bereits erwähnt, Datentyp umstellen auf Währung.
Double ist da ungeeignet.

Eine Alternative wäre noch Dezimal.

Hallo Klaus,

nochmal nein, es handelt sich nicht um eine Währung. Mir geht es um eine Anzahl oder Stück.

Kommt auch so in der Formel vor, Nennwert bzw. Stueck.

Wenn ich es richtig verstehe nimmt man überall dort, wo genau gerechnet werden soll, den Datentyp Währung und stellt am Ende auf Standardzahl?

LG - Wolfgang

Hallo,
ich muss noch mal nachbohren.
Völlig unbeachtet Deiner Formel, was ist der Nennwert ?
Bitte beziehe Dich nur auf dieses eine Feld.

ZitatNennwert bzw. Stueck.

es muss eher heißen Nennwert und Stück, beide Felder kommen in Deiner Formel vor.

Kann es eigentlich bei den Stückzahlen Dezimalzahlen geben, also z.B. 15,5 Stück ?

Hallo Klaus,

ganz schön neugierig  ;D

Dann mal genauer. Also im Prinzip hast Du recht, der Nennwert wird normalerweise in einer Währung angegeben.

Was ich aber benötige ist ein Bestand in einem Depot. Dort gibt es Anleihen die zu einem Nennwert gehandelt werden, und Fonds oder Aktien, die in Stück gehandelt werden. Die Kurse für Anleihen sind in Prozent, daher muss bei der Berechnung der Nennwert durch 100 geteilt werden.

Und jetzt die Formel:
Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert]/100)+Nz([Stueck]);Nz(0-([Nennwert]/100))+Nz(0-[Stueck]))

[tblKonto]![Art]=4 das bedeutet es handelt sich um einen Kauf, daher für den Bestand Nennwert / 100 oder Stueck
im anderen Fall handelt es sich um einen Verkauf, daher 0- (Nennwert / 100) bzw. Stueck zur Verminderung des Bestandes.
Die Bildung der Summe erfolgt in einer weiteren Abfrage.

Zu Deiner zweiten Frage:
Ja, es gibt Dezimalzahlen

Ich bin mit den ganzen Abfragen nicht glücklich, bekomme es aber nicht eleganter hin. Im Moment bekomme ich die Berechnung des Depotbestands zwischen zwei Terminen nicht ermittelt und breche mir schon seit einigen Tagen die Ohren.

LG - Wolfgang

Hallo,
also doch Währung.
Wie ich in #5 schon schrieb:

ZitatDaher ist es unerlässlich sobald eine Währung ins Spiel kommt auch Währung als Datentyp zu verwenden.

Stelle also den Datentyp auf Währung um, und Du bist den Fließkommafehler los.
Das ist ja der Sinn des Datentyps Währung, Fließkomma zu vermeiden.

Hallo Klaus,

jein!  ;D

Stueck ist eben nicht Währung. Und mir geht es eigentlich nur um die Zahl.

Und die Frage ist noch nicht beantwortet:
Wenn ich es richtig verstehe nimmt man überall dort, wo genau gerechnet werden soll, den Datentyp Währung und stellt am Ende auf Standardzahl?

Und wenn ja, wozu ist dann die Einstellung mit Fließkomma gut?

LG - Wolfgang

Hallo,

ZitatUnd wenn ja, wozu ist dann die Einstellung mit Fließkomma gut?

Das muss der Anwender entscheiden. Wenn man aus Länge und Breite die Größe eines Grundstücks ermitteln will, kann man sicher Double verwenden.

Natürlich ist die Frage beantwortet:

ZitatStelle also den Datentyp auf Währung um, und Du bist den Fließkommafehler los.

Das Format ist egal bzw.muss auf einen passenden Wert eingestellt werden.
Wenn das Ergebnis eine Währung ist, dann Währung, eine Kommazahl als Standardzahl mit den gewünschten Kommastellen (maximal 4)

Hallo,

leider muss ich nochmal auf das Thema zurückkommen. Ich bekomme das Problem nicht gelöst. Bei einer Abfrage auf "0" erhalte ich immer noch ein falsches Ergebnis.

In den Auswertungen geht es um eine Menge, die in Stück oder Nennwert angegeben sind. Dabei handelt es sich bei Nennwert nicht um eine Währung. Die Angabe einer Währung ist dabei lediglich eine weitere Information. So wie es sich bei Obst zum Beispiel um Äpfel oder Birnen handeln könnte.

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

LG - Wolfgang

Zitat von: Ratoncito am April 05, 2020, 13:25:19
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:
? 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.

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

Zitatbei 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.

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

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

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

@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.

Zitat
1,02140518265514E-14

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

Zitatwerden Berechnungen durchgeführt

Dazu aber auch eine Bemerkung:
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.

Zitat von: ebs17 am April 05, 2020, 20:18:18
@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:? 70 - 58.66 - 11.34
3,5527136788005E-15

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".

Zitat von: DF6GL am April 05, 2020, 14:15:48
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.

Zitat von: DF6GL am April 05, 2020, 14:15:48

Zitatbei 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.

Zitat von: ebs17 am April 05, 2020, 20:18:18

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.

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
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
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
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

Hallo,

Zitatdass 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.

Hallo,

ZitatDer 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...

Hallo Franz,

ZitatBei "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

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.

Hallo,

Zitat von: DF6GL am April 06, 2020, 13:22:07
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

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.

Hallo,

ZitatIch 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... ::)

ZitatBei 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.

Zitatund 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:
1,02140518265514E-14
Wenn man das auf zwei Nachkommastellen rundet: Was kommt da wohl heraus?
Runden (http://www.donkarl.com?FAQ2.1)

OT:

Zitat1,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

Hallo,

Zitat von: Ratoncito am April 05, 2020, 13:25:19
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

@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

Hallo,
warum hast Du in der letzten Abfrage den Bestand als berechnetes feld zugewiesen:
Bestand: Bestand
Hier in der Abfrage Euro als Format einzustellen ist sinnlos. Eine Formatzuweisung hat mit dem Datentyp nichts zu tun.

Ansonsten:

ZitatWenn Du nicht weiter kommst, erstelle ein kleines Beispiel,

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

Hallol,

ZitatIn 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.

@Ratoncito

ZitatDie 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

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.

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

Hallo Klaus,
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

Hallo,

darf ich nochmal hierauf zurück kommen?

Zitat von: Ratoncito am April 09, 2020, 10:30:28
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

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

Hallo,

Zitat von: DF6GL am April 12, 2020, 09:58:53
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.

Zitat von: MzKlMu am April 08, 2020, 11:47:06
Für die Rechengenauigkeit ist ausschließlich der in der Tabelle angelegte Datentyp zuständig.

Zitat von: MzKlMu am April 07, 2020, 10:16:07
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.

Zitat von: DF6GL am April 12, 2020, 09:58:53
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

Hallo,
wie von Franz gesagt:

ZitatDer "/" 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 ?

Zitatein 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).
 

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.

Hallo,

ZitatSorry, das stimmt so nicht.

Ja, da hast Du Recht.  Es sind soviel:

X = 1/0,001000000001

Hallo,

Zitat von: MzKlMu am April 12, 2020, 11:56:31

ZitatDer "/" 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

Hallo,

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

Wenn Du das jetzt immer noch nicht weißt, dann solltest Du Dich wirklich zunächst und als Erstes mit den Grundlagen von Access und allgemein mit der Wirkungsweise von Funktionen und mathematischen Ausdrücken bei der VBA-Programmierung intensiv beschäftigen, z. B. mit Tutorials und Fachbüchern.

Ohne diese Kenntnisse  wirst Du Deine (gleichen) Fragen immer wieder stellen und die Antworten nicht verstehen.

Zitat..wo und wie CCur eingesetzt werden sollte..

Ist Dir denn bekannt, was diese Funktion bewirkt?  Stelle den Cursor (Schreibmarke) im VBA-Editor auf diese Funktion und drück F1.. 

Einsetzen musst Du die Funktion dort, wo sie erforderlich ist oder wird, soll heißen in irgendeiner Berechnung (in Abfragen, in Steuerelementinhalten, in VBA-Prozeduren,  wo denn sonst..), wie schon öfters gezeigt.

Zitat
Das Nz hatte ich verwendet, weil leere Felder einen Fehler in der Wenn-Formel verursachten.

Im Grunde ist das richtig, nur die NZ()-Funktion ist syntaktisch und logisch falsch eingesetzt.

Die NZ()-Funktion macht nur Sinn, wenn sie auf ein Feld/Variable (nicht mathematischer Ausdruck) mit Datentyp Variant wirkt.

Die NZ()-Funktion auf einen mathematischen Ausdruck anzuwenden, ist Unsinn,  weil ein solcher Ausdruck nie NULL (nichts, leer, nicht existent) sein kann.  NULL ist hier nicht der Wert 0.

Zitataber mir und anderen Anfängern immer wieder Probleme bereiten

Das ist uns bekannt, und wir helfen gerade deswegen ja auch...   Nur sollten die Ratschläge und Lösungen auch mal durchdacht und verstanden werden und auch einen gewissen Fortschritt zeigen.

Hallo,
beantworte mal noch diese Frage:

ZitatKann der Nennwert und/oder Stück NULL sein ?

Grundlegend: Ein Computer rechnet immer noch wie vor 50 Jahren mit dem Binärsystem (Bit: 1 oder 0), vervielfältigt dann auf Bytes (8 Bit) und Vielfache davon. Das Dezimalzahlensystem, mit dem wir gewohnt sind umzugehen, ist ein ganz anderes. Die Umrechnung hat ihre Tücken, was sich weniger bei Ganzzahlen, aber eben bei Teilen von Ganzzahlen (=> Dezimalstellen) darstellt. Der mögliche (Rest)Fehler stellt sich in der Fließkommazahlenproblematik dar. Das hat jetzt mit Access nur so weit zu tun, dass auch Access einen Computer und dessen Betriebssystem benutzt.

Höhere Genauigkeiten (Festkomma statt Fließkomma und damit Vermeidung von Umrechnungsresten) werden über andere Datentypen mit größeren Bytebreiten erkauft, also mit mehr Aufwand zum Rechnen.

Wenn man jetzt rechnet, kommt einiges zusammen:
- Datentypen der Ausgangswerte
- Art der Berechnung

Bei einer Berechnung eines Ausdruckes in einer Jet-Abfrage wird der resultierende Datentyp des Ergebnisses i.d.R. von Jet selber ermittelt und vergeben, und da wird in die ganz kleine Kiste gegriffen (=> Long, Double, Text, Boolean - man will ja sparen), für resultierende Dezimalzahlen also Double mit der vielfachst erläuterten Fließkommazahlenproblematik. Ein CCur darauf kommt erst nachträglich zur Wirkung, kann also helfen durch Abschneiden von Dezimalstellen (die aber entstanden sein können), muss es aber nicht, weil es erst später zur Wirkung kommt. So etwas würde aber ein zielgerichtetes Runden sauberer, nachvollziehbar und steuerbar auch ausführen.
CCur ... ist eine Konvertierungsfunktion (Typumwandlungsfunktion: ein Datentyp in einen anderen). Bei einem Umrechnen können auch Späne entstehen. Hin- und Herrechnen macht vielen richtig Spaß. Aber: Aufwand ist es allemal, der sich summiert irgendwann auch auf die Laufzeit niederschlagen kann. Und wie sagt der Klimaschützer: Über das Treibhausgas, das ich nicht erzeuge, muss ich mir nicht die Gedanken machen, es zu entsorgen oder mit dessen Problemen zu leben.

Ist das verständlich?

Nz ... ist eine Funktion des Access-Objektes.
Felder einer Datenbanktabelle dürfen, wenn nicht explizit ausgeschlossen, nichts (=> NULL) enthalten. NULL ist das Unbekannte, Nichtdefinierte. Damit kann man nicht rechnen, nicht vergleichen, daher kommen auch Fehler bei unmittelbarer Verwendung.
0 und NULL ist ein Riesenunterschied. Schulden vom Wert 0 ist etwas ganz anderes als Schulden ungebannter Größe.

Per Nz kann man für einen NULL-Inhalt einen Ersatzwert setzen. Also tun wir bei Zahlen z.B. so, dass Schulden, die nicht bekannt sind, den Wert 0 haben. Mit 0 kann man mathematisch weiterrechnen und hat dann nur bekannte Fehler, z.B. bei Division durch 0.

Ein Nz auf eine Konstante ( 17, 23, 0) macht überhaupt keinen Sinn, noch weniger, als wenn man sein angeheiratete Ehefrau täglich fragt, ob sie eine Frau ist, denn dieses könnte sich womöglich ändern. Eine Konstante heißt konstant, weil sie konstant ist.
Prüfen und ggf. ersetzen müsste man also nur, was sich wirklich ändern kann, also immer nur den Tabellenfeldinhalt als Quelle an sich. Eine Prüfung auf einen Berechnungsausdruck ist dann nur ein schlecht gemachtes Alibi, weil es zeigt, dass man Grundlagen gar nicht verstanden hat. Zudem wird es dann unpräzise und erschwert eine Fehlersuche - das Schießen in den Nebel verspricht eine geringere Trefferwahrscheinlichlkeit.

Was hast Du jetzt besonders gut verstanden.

Hallo,

vielen Dank für die ausführlichen Antworten.
Fundierte Kenntnisse erleichtern ohne Frage die Erstellung einer DB oder die Lösung der dabei auftretenden Probleme. Aber irgendwann beginnt man mit einem kleinen, einfachen Projekt. Mit der Zeit werden diese anspruchsvoller...
Wir alle schlagen uns jährlich erneut mit unserer Steuererklärung herum obwohl die wenigsten Steuerberater sind.  :)

Zitat von: MzKlMu am April 12, 2020, 18:25:40
Hallo,
beantworte mal noch diese Frage:

ZitatKann der Nennwert und/oder Stück NULL sein ?

Ja.

Nach dem Hinweis von Beaker s.a. habe ich die Tabelle geändert. Statt der Felder Nennwert und Stueck gibt es nur noch ein Feld Anzahl. Durch die nötigen Änderungen in Formularen, Abfragen und VBA ist mein ursprüngliches Problem beseitigt.
Bei dieser Gelegenheit habe ich direkt alle Felder, die an Berechnungen beteiligt sind, auf Datentyp Währung umgestellt.

Zitat von: ebs17 am April 12, 2020, 23:09:55
Ein Nz auf eine Konstante ( 17, 23, 0) macht überhaupt keinen Sinn, noch weniger, als wenn man sein angeheiratete Ehefrau täglich fragt, ob sie eine Frau ist, denn dieses könnte sich womöglich ändern. Eine Konstante heißt konstant, weil sie konstant ist.

Mit dem was in der heutigen Zeit alles möglich ist...
Von Zeit zu Zeit sollte man da eventuell doch mal prüfen  :D

Nochmal vielen Dank für die Erklärungen.

LG - Wolfgang