Zahlen mit Nachkommastellen in SQL
Carsten Pache
Datensatz an eine Tabelle anfügen. In eines der Felder soll eine Zahl
mit Nachkommastellen eingefügt werden. "Soll", denn an dieser Stelle
erhalte ich immer eine Fehlermeldung bezüglich eines Kommas im
SQL-String. Trifft ja auch unglücklich zusammen, daß das in Deutschland
übliche Komma bei Dezimalzahlen gleichzeitig auch das Trennzeichen
innerhalb eines SQL-Strings ist. Aber irgendwie muß eine Zahl vom Typ
"Double" oder "Single" doch mittels SQL zu verarbeiten sein!
Wer weiß Rat?
--
Mit freundlichen Grüßen
Carsten Pache
Achim Seelbach
innerhalb von vba gilt grundsätzlich die us-amerikanische
laendereinstellung.
Auch für SQL-String-Eigenschaftswerte/Methodenparameter ist das Komma das
Listentrennzeichen, als Dezimaltrennzeichen ist der Punkt (".") zu
verwenden.
Die deutsche Ländereinstellung ist lediglich - fuer die interaktive Nutzung
- in den Entwurfansichten von Access-Objekten relevant.
Die Angabe einer Dezimalzahl in VBA koennte sein: 4.56
mfg achim
Andrea Philipp
Dein Problem läßt sich einfach lösen, wenn Du den Wert mit der Funktion
Str(Zahl) im SQL-String umwandelst.
Gruß Andrea
Werner Ihmann
hatte leider ebenfalls diese Problem.
Kombobox enthält numerische Werte (natürlich mit Komma)
der Inhalt dieser Kombobox sollte in ein Feld einer Tabelle geschrieben
werden.
mir blieb nur folgende Möglichkeit, den von der Kombobox gelieferten Text
mit
einer selbst-geschrieben Funktion in einen für SQL akzeptablen Text (Punkt
statt Komma)
zu konvertieren.
mfg
Werner
Carsten Pache <carste...@snafu.de> schrieb im Beitrag
<36796AEA...@snafu.de>...
Carsten Pache
mir Str(Zahl) hat es geklappt, vielen Dank! Die importierten Zahlen
enthalten nun noch zwei Dezimalstellen, die durch einen Punkt (nicht
durch ein Komma) vom ganzzahligen Teil der Zahl getrennt sind. Daher muß
ich die Zahl erst durch 100 teilen, da Str(Zahl) den Punkt nicht als
Dezimaltrennzeichen versteht. Beim manuellen Access-Import (Datei -
Externe Daten -Importieren) werden die Punkte dagegen korrekt
umgewandelt. Doch damit kann ich leben (solange es sich um eine feste
Anzahl Dezimalstellen handelt).
Grüße aus Hamburg
Carsten
Andrea Philipp schrieb:
Carsten Pache
das habe ich auch zuerst probiert, erschien mir dann aber zu
umständlich. Beim Einfügen des Wertes mit Punkt hatte ich auch das
Problem, daß der Wert (bei zwei Dezimalstellen) immer um den Faktor 100
zu groß war, der Punkt also beim Einfügen in das Feld nicht wieder in
ein Komma umgewandelt wurde.
Grüße aus Hamburg
Carsten
Werner Ihmann schrieb:
Carsten Pache
die zu importierenden Werte enthalten einen Punkt als
Dezimaltrennzeichen. Einige Werte werden vor dem Einfügen in die Tabelle
jedoch durch einen Faktor geteilt, wobei ein Wert mit Komma als
Dezimaltrennzeichen entsteht, der vom SQL-String dann falsch
interpretiert wird. Zur Überprüfung habe ich den SQL-String mit
debug.print ausgeben lassen und konnte daran erkennen, daß aus einem
Punkt ein Komma wurde (mit den entsprechenden Konsequenzen...).
Grüße aus Hamburg
Carsten
Achim Seelbach schrieb: