MySQL will 250.53 Lazrus erzeugt jedoch 250,53

[Alfred]

Ich lese mit tbf eine *.dbf aus.

dbfak := dbf1.fields[8].AsFloat;

In der dbf steht in diesem Feld 250.53(mit Hexeditor geprüft).

Nun möchte ich diese Zahl in eine MySQL-Datenbank wegschreiben.
Diese erwartet 250.53.

SQLQUERY1.Fields[9].AsCurrency := dbfak;

liefert jedoch 250,53.

Gruß
Alfred

[monta]

Code: Alles auswählen

DecimalSeparator := '.'

und dein Problem sollte erledigt sein.

[Alfred]

Hallo Monta,

funktioniert prima.

Gruß
Alfred

[af0815]

Es ist eine gute Idee DecimalSeparator und ThousandSeparator richtig zu setzen, damit ist dann bei Zahlen immer auf der richtigen Seite.

[ghieber]

Ich weck mal den alten thread wieder auf:

Alles unter WinXP:

ich bin per TMySQL50Connection - TSQLQuery - TDatasource mit einer MySQL 5.1 Datenbank verbunden und zeige das Ergebnis der Abfrage in einem DBGrid an. alles ok, Gleitkommawerte werden mit Komma angezeigt und lassen sich auch so editieren. Sobald ich ApplyUpdates der Query aufrufe kommt die Fehlermeldung der Datenbank.

DecimalSeparator auf '.' zu setzen behebt das Problem, allerdings ist das nicht befriedigend. das Komma im Ziffernblock der deutschen Tastatur ist nicht mehr nutzbar, und die Anzeige entspricht nicht mehr der Landeseinstellung.

Ich habe mir den Quellcode der TSQLQuery angeschaut. in "ApplyUpdates" wird einmal der SQL - String für den Update zusammengesetzt, und dann eine TParams - Struktur mit den eigentlichen Werten gefüllt. Ich vermute, dass dabei intern die selbe Formatierungsroutine (FormatFloat, FloatToStr ??) verwendet wird wie bei der Anzeige. Vermuten heißt nicht wissen!Damit ist aber der SQL - Fehler unvermeidlich, sobald ein anderes Dezimaltrennzeichen als der Punkt voreingestellt ist.

Weiß irgend jemand, ob diese Vermutung stimmt? und hat jemand eine Idee für einen Workaround? Oder gibt es vielleicht noch etwas, was ich übersehen habe?

Grüße, Georg

[af0815]

Oder gibt es vielleicht noch etwas, was ich übersehen habe?

Am besten sich den SQL-Kommandostring von MySQL direkt anzeigen/monitoren lassen, dann sieht man welcher String (und somit welches Problem) wirklich zur DB rüberkommt.