Wie sauber mit Double Werten arbeiten?

[Hondo]

Hallo,
ich stoße immer wieder mal auf das Problem dass Double-Werte eingegeben/gespeichert werden und frage mich wie man das sauber machen kann.
Problem ist ja dass man die Eingabe mit einem Komma machen muss (bei Punkteingabe wird z.B. aus 1.5 eine 15 wenn man den Double-Parameter übergibt).
Beim Speichern per Aktualisierungsabfrage muss aber zuvor das Komma in einen Punkt umgewandelt werden, dann läuft die Aktualisierung durch. In der Tabelle wiederum steht dann der Wert wieder mit einem Komma.
Das ist ganz schön Konfus.

Desweiteren, gibt man in eine Textbox den Eingabewert mit Punkt ein, und vergleicht ihn mit einem Long, dann geht das Wirrwarr weiter.
im Direktbereich getestet: ?1.5>2    => Ergebnis Falsch was ja korrekt ist.
Im VBA-Code aber:
if Me.EingabeKommaWert > 2 then Beep   => Ergebnis Beep was ja falsch ist.
If cdbl(Me.EingabeKommaWert) > 2 then Beep   => Ergebnis Beep, was auch falsch ist.

Fazit: es ist kaum möglich gescheit mit Kommawerten und Double zu arbeiten.
1. Bei allen Eingaben muss die Eingabe auf Punkt geprüft werden und in ein Komma umgewandelt werden
2. Bei allen Aktualisierungs- und Einfügeabfragen den Wert mittels replace(Komma->Punkt) bearbeiten.
3. Bei allen Vergleichen im VBA-Code ebenfalls mit replace(Punkt->Komma) arbeiten.

Das ist total bescheuert.
Wie macht ihr das? Gibts dazu ein Königsweg?

Gruß Andi

[Doming]

Hallo Andi,

auch wenn das jetzt nur ein workaround ist: Wie wäre es, ein unsichtbares Feld zu integrieren, welches die eingegebene Zahl sofort mit Punkt darstellt? Bei Berechnungen dann nur mit dem Schattenfeld arbeiten.

Gruß
 Doming

[Bitsqueezer]

Hallo Andi,

das ist ein Problem der Regionaleinstellung.
Wenn Du "1.5" in ein gebundenes Feld eingibst, was Double ist, und die Regionaleinstellungen besagen, daß "." das Tausendertrennzeichen ist, wird es beim Speichern aus dem Wert rausgeworfen. Aus "1.5" wird "15" und 15 ist halt > 2, also alles korrekt.

Wenn Du in VBA mit Zahlen arbeitest, dann ist selbstverständlich IMMER der Punkt entscheidend, da es hier keine regionalen Einstellungen gibt. Außer bei den "C"-Funktionen zum Konvertieren, also etwa:

Code [Auswählen] Erweitern

?cdbl("1.5")
15 Bei deutschen Regionaleinstellungen ist es hier also das gleiche - der Punkt wird entfernt und Du hast eine 15.

Daher wäre wohl eher die Frage: Warum gibt man in einem deutschen Access "1.5" als Kommazahl ein? Auch die Zehnertastatur hat auf einer deutschen Tastatur ein "," und keinen Punkt. Gibst Du also korrekt "1,5" ein, hast Du keine Probleme.

Code [Auswählen] Erweitern

?cdbl("1,5")
1,5
Die Zahl wird auch in VBA mit Komma ausgegeben, auch wenn VBA selbst intern nur "." verwendet.

Wenn User eine englische Regionaleinstellung haben, dann funktioniert es umgekehrt. Die Tastatur hat dann auch einen ".", da wo wir ein "," haben, es wird ein Punkt als Dezimaltrennzeichen verwendet und wenn jemand "1.5" eingibt, dann wird es auch so gespeichert.

Also nein: Bei den Eingaben muß das nicht getestet werden. Der englische User gibt "." ein, der deutsche ",". Es ist nicht die Aufgabe der Anwendung, dem User beides zu erlauben. Wer "." in einem deutschen Windows als Komma eingibt, wird sofort sehen, daß er "15" hinterläßt. Der User müßte schon eine englische Tastatur haben, um überhaupt "." einzugeben, weil die meisten bei Zahleneingaben die Zehnertastatur verwenden.
Aber selbst wenn es z.B. eine schmale Tastatur wie bei einem Laptop ist ohne Ziffernblock - welcher deutsche User gibt "." ein für ein Dezimalkomma?

Deine Ifs sind also völlig richtig, wie sie sind. Wird "1,5" eingegeben, bleibt es in einem deutschen Windows auch bei 1,5 und nicht 15.

Bei Abfragen muß auch nichts mit Replace ersetzt werden. Wenn man keine Abfrage als Strings zusammenpuzzelt, sondern, wie man es korrekt macht, eine Parameterabfrage erstellt, dort den Datentyp vorgibt und dann eine QueryDef verwendet und die Parameterliste direkt befüllt, regelt Access das alles automatisch. Da braucht es kein CDbl, kein Replace etc., Access stellt den Parameter ein, wie er vom Feld kommt und es gibt keine Probleme.
Denn das gebundene Feld ist ein Double und damit weiß Access, wie es mit "Value" umzugehen hat, auch wenn eine Textbox immer einen Textwert verwendet und der Wert implizit automatisch umgewandelt wird.
Darum möglichst nie mit ".Text" arbeiten (was nur geht, solange man noch den Fokus auf der Textbox hat), weil das den String zurückgibt. Immer nur mit dem Default ".Value" (egal, wo der Fokus steht), weil das aus dem Inhalt der Textbox automatisch einen Double zurückgibt (wenn gebunden an ein Double-Feld). Das kann man mit VarType nachprüfen, was bei ".Text" eine 8 (String) ist und bei ".Value" eine 5 (Double).

".Value" gibt natürlich den richtigen Wert erst "AfterUpdate" (bzw. schon bei "BeforeUpdate") wieder, während der Eingabe geht nur ".Text". Das ist aber nur in seltenen Spezialfällen nötig, mit ".Text" arbeiten zu müssen.
In "Feld_BeforeUpdate" etwa steht der Eingabewert bereits für ".Value" zur Verfügung, obwohl der Datensatz noch nicht gespeichert wurde.


Parameterabfrage als Beispiel:

Code [Auswählen] Erweitern

PARAMETERS parNeueZahl IEEEDouble,
parID Long;

UPDATE tblTest
SET
    tblTest.F_Zahl2 = parNeueZahl
WHERE
    ID = parID;

Und in VBA:

Code [Auswählen] Erweitern

    Dim qd As DAO.QueryDef
    Dim db As DAO.Database
   
    Set db = CurrentDb
    Set qd = db.QueryDefs("qryUpdateTest")
   
    qd.Parameters("parNeueZahl") = Me.ctl_F_Zahl
    qd.Parameters("parID") = Me.ctl_ID
   
    qd.Execute
(Hier der Einfachheit halber die Zahl aus dem ersten Feld in das zweite der aktuellen ID kopiert.)

Die Ausgabe der Werte wird ebenfalls 1:1 aus den Windows-Einstellungen übernommen. Wenn das Windows auf Deutsch eingestellt ist, zeigt die Tabelle beim Öffnen alle Werte mit "," und ggf. ".", wenn Tausenderpunkte in der Formatierung mit ausgegeben werden sollen. Bei englischem Windows - ohne etwas umzuprogrammieren - mit "," für Tausender und "." als Dezimalpunkt.

Auch VBA gibt die Werte im Direktfenster mit "," aus im deutschen Windows. Im englischen mit ".".

(Nur nochmal betont: Hat nichts mit den Spracheinstellungen zu tun, die ändern nur i.d.R. auch die Regionaleinstellungen für Zahlen und Datum und mehr, man kann aber ebenso Sprache auf Englisch einstellen und danach die Regionaleinstellungen für Zahlen und Datum auf deutsche Variante ändern, das sind getrennte Einstellungen.)

Wenn Du ".Value" verwendest, brauchst Du auch kein Replace für Wertevergleiche. Für VBA ist es dann ein Double.

Wenn Du dagegen ein ungebundenes Feld hast, dann weiß Access natürlich auch nicht, daß da eine Zahl drin ist, dann ist der VarType immer 8 (String). Da gibt es dann keine Regionaleinstellungen, die angewendet werden könnten.

Hier kannst Du "Val" verwenden, dann wird eine Zahl mit "." als Dezimalkomma auch genau so verwendet.
Willst Du die Zahl nach Regionaleinstellung verwenden, dann "CDbl", dann wird aus dem, was in den Regionaleinstellungen steht, das Dezimalkomma.

Gebe ich "1.4" in das Feld ein, dann gilt bei deutschen Regionaleinstellungen:

Code [Auswählen] Erweitern

?val(Form_frmTest.Text16)
 1,4
?cdbl(Form_frmTest.Text16)
 14
Denn Val verwendet immer "." als Dezimalkomma, CDbl immer die Regionaleinstellung.
Ist Region Englisch eingestellt, gibt auch CDbl "1.4" aus (weil dann auch die Ausgabe in beiden Fällen "." verwendet, auch im Direktfenster).

Gibt man "1,4" ein im deutschen Windows, ist es daher umgekehrt (nur daß "Val" beim ersten Zeichen aufhört, was für Val kein Bestandteil einer Zahl ist, während CDbl einfach das jeweils eingestellte Tausenderzeichen entfernt):

Code [Auswählen] Erweitern

?val(Form_frmTest.Text16)
 1
?cdbl(Form_frmTest.Text16)
 1,4
Für eine Parameterabfrage wäre also je nach Wunsch Val oder CDbl zu verwenden, auch hier kein Replace notwendig.
Es geht hier aber auch ohne: Access konvertiert die Zahl nach Regionaleinstellung, wenn man einfach nur schreibt:

Code [Auswählen] Erweitern

qd.Parameters("parNeueZahl") = Me.Text16
Vorausgesetzt natürlich, es wurde "," eingegeben und im englischen Windows ein ".".

Du kannst es natürlich forcieren, indem Du die Tasten mit den Key-Events abfragst und "," automatisch gegen "." austauschst oder umgekehrt. Würde ich aber nicht machen: Der User kennt seine Regionaleinstellung und sollte auch seine Regionaleinstellung verwenden können. Darum ist es ja gerade gut, daß Access die Regionaleinstellungen verwendet (und auch noch dynamisch, auch bei gestarteter Anwendung kann man die in Windows ändern und Access reagiert sofort darauf).

Das ganze gilt natürlich auch für z.B. Datumswerte.

Gruß

Christian

[Knobbi38]

Wenn Du dagegen ein ungebundenes Feld hast, dann weiß Access natürlich auch nicht, daß da eine Zahl drin ist, dann ist der VarType immer 8 (String). Da gibt es dann keine Regionaleinstellungen, die angewendet werden könnten.

Tip: Das Format der ungebundenen Textbox auf "allg. Zahl" einstellen, dann wird wieder Double angenommen.

Und was die Val() Funktion betrifft, sollte man damit vorsichtig umgehen, denn hier wird ein String! in einen passenden numerischen Wert konvertiert, wobei nur der Punkt als Dezimaltrennzeichen akzeptiert wird. Übergibt man einen anderen Datentyp als Argument, wird das also immer erst implizit in einen String konvertiert, was ebenfalls eine Fehlerquelle sein kann. Auch muß man ein paar Seiteneffekte berücksichtigen, z.B. das Datentypkennzeichen anders interpretiert werden als erwartet.

Sieh auch: https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/val-function
 

Knobbi38