Office: (Office 2003) Listenfeld ja nein wird nun als -1 und 0 angezeigt

kaufmännisches Runden ist nun mal die Standardrundung. Die Rundungsfunktion von Access ist daher im Grunde unbrauchbar.

Größere Probleme bereitet auch Ungenauigkeit der eingebauten Funktion. aufgrund. Alleine deshalb sollte schon nicht die Access-Funktion verwendet werden.

Gruß
Helmut

 

Wenn man kaufmännisches Runden anwenden will, dann kann man natürlich nicht die in Access mitgelieferte Round-Funktion verwenden. Deshalb ist diese Funktion aber nicht falsch.

Kannst du mir ein Beispiel zeigen, bei dem die Round-Funktion aufgrund Ungenauigkeiten ein falsches Ergebnis liefert?

 

\@Josef

Das mit der Genauigkeit wurde schon mehfach hier im Forum diskutiert. Bitte die Suche benutzen.
Genaues Beispiel habe nicht zur Hand, weil ist die Funktion deshalb nicht nutze. Verwende immer meine eigene Prozedur.

 

Die benutzte ich - nur fand ich kein Beispiel, bei dem Rundungfehler bei mathematischen Runden beschreiben wurde.
Vielleicht drückte ich mich auch nicht verständlich genug aus. Ich will nur Klarheit schaffen, dass es immer auch auf die richtige Anwendung einer Funktion ankommt. Wenn eine Funktion fälschlicherweise angewendet wird, um ein Ergebnis zu erhalten, wofür diese Funktion nicht geschrieben wurde, ist es kein Fehler der Funktion sondern von den Programmieren die diese Funktion dafür einsetzen.

Ich habe nur immer wieder den Eindruck, dass in Access einige Methoden nicht verstanden werden und dann das einfach als Bug abgehandelt wird.

Wenn ich dir die Aufgabe stelle, 5 und 7 zu addieren, verwendest du auch nicht zur Ermittlung des Ergebnisses 5*7 und behauptest dann, der Operator * liefert ein falsches Ergebnis, oder?
Aber genau diesen Eindruck habe ich in den Diskussionen über die Round-Funktion, die mathematisches Runden verwendet, von der aber in den vielen Beiträgen das Ergebnis des kaufmännischen Rundens erwartet wird.

mfg
Josef

 

Ich habe dies mit einem kleinen zwischenschritt behoben. Ich habe mir dieses als eins Anzeigen lassen und dann mit ner WENN Formel ein JA oder NEIN raus gemacht funktioniert rekativ schnell versuch es mal^^

 

\@rene

das habe ich ja schon in meinem Eingangsposting erwähnt. Es gibt diese Lösung, nur ist das bei über 100 Abfragen bzw. 100 verschiedenen Listenfeldern viel Aufwand

Gruß
Helmut

 

möglicherweise lässt sich das auch automatisieren. Bin mir aber nicht sicher, ob der Aufwand der Codierung und die Fehlergefahr nicht größer ist, als das manuelle Ändern der betroffenen Abfragen für die Listenfelder.

eine Automatisierung könnte ich mir so vorstellen:
- alle Formulare nach Listenfeldern absuchen
- die Datenherkunft der Listenfelder (z.B. per Recordset) auswerten und darin nach Boolean-Typ-Feldern suchen um diese dann umschreiben.

Dabei ist es aber wichtig, dass das nicht einfach so umgeschrieben wird, denn falls diese Spalten der Listenfeldern im Form-Code verwendet werden, wird nach der Änderung ein falsches Ergebnis geliefert.

So gesehen, würde ich selbst das Risiko vermutlich nicht eingehen und manuell ändern.

 

Mensch, Josef tut immer so geheimnisvoll *wink.gif* Der Witz daran ist einfach, das mathematisch immer auf die nächste gerade Zahl auf- bzw. abgerundet wird.

Auf 2 Nachkommastellen:

1,075 ---> 1,08
1,085 ---> 1,08

 

Das dachte ich ja auch, deshalb habe ich das ja auch nicht verstanden. *rolleyes.gif*

 

Ah! ... jetzt glaube ich das Problem zu verstehen.
Mit Ungenauigkeit meinte Helmut gar nicht die Ungenauigkeit der Funktion sondern die Ungenauigkeit bei Double-Zahlen.

Beispiel:
Code:

Genau für diesen Fall ist in der Rundungsfunktion aus FAQ 2.1 der "Trick" mit Fix("" & varZahl ...
ohne dieses Leerzeichen-"Addition" würde auch diese Rundungsfunktion unterschiedliche Ergebnisse liefern.

@anne:

Das passt doch, oder?
aus 1.035 wird 1.04 ... also wird aufgerundet
aus 1.025 wird 1.02 ... es wird abgerundet.
aus 1.02500001 wird 1.03, da die Zahl nicht mehr genau zw. 1.02 und 1.03 bzw. näher an 1.03 liegt.

 

\@Josef

A) ja genau es hängt mit dem Datentypen zusammen.

B) Ich werde die manuelle Variante der Editierung wählen, alles andere ist nicht sehr sicher.

 

Lieber Josef,
auch die mehrfache Wiederholung bringt mir leider keine Erleuchtung. Die Rundungsregel, die in FAQ 2.1 erwähnt wird, war mir nicht bekannt - zum Glück muss ich in meinen Anwendungen nicht rechnen, zumindest nicht kaufmännisch korrekt. Den Hinweis bzw. die Erklärung hättest du ruhig schon eher geben dürfen, in der Access-Hilfe habe ich danach vergeblich gesucht. *rolleyes.gif*

 

tut mir leid, besser kann ich es nicht beschreiben - da ich leider das Verständnisproblem nicht erkenne.
Suchte mir aber nun den Link auf den Wikipedia-Artikel heraus, dort sind die verschiedenen Rundungsarten angeführt. (ich gehe aber davon aus, dass du dort schon nachgeschlagen hast)
Wenn du mir erläuterst wo ich mich nicht klar genug ausdrückte, versuche ich es gerne noch einmal.

Naja, ich hätte auch gar keine Erklärung geben können - wollte aber die Bug-Behauptung zu Round widerlegen. *wink.gif*

 

\@Josef: Ich bezog mich auf folgende Aussage

auf die sich deine Beispiele ganz offensichtlich stützen. Die Rundung abhängig von geraden oder ungeraden Zahlen nach unten oder oben vorzunehmen kam mir zwar beim ersten Anblick schon in den Sinn, jedoch hatte ich das als ziemlich abstrus abgetan. (so habe ich das nicht gelernt *eek.gif* )

 

So noch abschließend:

Ich habe zur Erleichterung eine kleine Funktion geschrieben, die den Boolean ausdruckt sauber in den String "ja" oder "nein" umwandelt.

Diese Funktion kann dann ohne viel Aufwand in der ganzen Anwendung (auch in Abfragen) verwendet werden.

Es reicht dann in Abfragen

jaNeinFeld: my_jn([FELD_boolean])

statt

jaNeinFeld: Wenn([FELD_boolean];"ja";"nein")

zu schreiben.

Gruß
Helmut