Hallo,
ich hoffe Ihr seit meine Rettung.

a) Ich hole aus einer Tabelle Q eine Summe (ADODataset)
b) Das Ergebnis ist 416,66666666666666.
c) Mittels ADOConmmand und SQL UPDATE will ich dieses Ergebnis in eine andere Tabelle einfügen.
Ich verwende brav Parameter. Es können viele Datensätze werden.

markieren

Code:

   dKost := FieldByName('intern').AsFloat;
   ...
   Parameters.ParamByName('I').Value := dKost;

Ergebnis in der neuen Tabelle = 41666666666666666
Ich dachte, weil dKost mit Komma ist.

Umgebaut zu Stingvariable sKost.

markieren

Code:

   sKost := FieldByName('intern').AsSting;
   ...
   Parameters.ParamByName('I').Value := StringReplace(sKost, ',', '.', [rfReplaceAll]);

Ergebnis der Variable = '416.66666666666666' mit Punkt
Ergebnis in der neuen Tabelle = 41666666666666666

Sowohl mit Komma als auch mit Punkt als auch als Float/Double immer das Gleiche.

Was passiert da?
Ich dachte eigentlich mit Parametern gibt es die Probleme nicht?

Was passiert bei:
Parameters.ParamByName('I').Value := FieldByName('intern').AsFloat; Value ist, soweit ich weiß, vom Typ Variant, da wird (glaub' ich) der Typ des übergebenen Wertes interpretiert.
Parameters.ParamByName('I').Value := FieldByName('intern').Value; Wenn Du die Daten von "Hand" in die Datenbank eingibst, musst Du dann als Dezimaltrenner das Komma oder den Punkt eingeben?

Ist das bei beiden Tabellen gleich?

Meine momentane Vermutung wäre, dass das Komma als Tausendertrenner erkannt wird und ist nicht für die Speicherung erforderlich. Daher wird's einfach entfernt.

Was passiert denn, wenn Du bei der Stringverarbeitung den Punkt drinne läßt?

In der DB Oberfläche kann ich die Zahlen mit Komma eingeben,
und sie werden auch mit Komma angezeigt und ausgewertet.

Mit Komma werden die Zahlen falsch interpretiert,
bei dem StringReplace wechsel ich ja das Komma zu einem Punkt.

Somit habe ich beide Varianten probiert.

Mit:

markieren

Code:

sqlText := 'UPDATE tSN_Budget SET [ist] = '+sKosti+', istEx = '+sKoste+' WHERE ( '
                       +'(Proj_Ident = '+QuotedStr(sProj_Ident)+') '
                       +' AND (LeistungsKlasse = '+QuotedStr(sLK)+') '
                       +' AND (Leistung = '+QuotedStr(sLeistung)+'))';

Gehts!!!

Woher soll ADO wissen, was für ein Typ der Parameter ist? Da stopfst Du irgendwas rein und das geht auch mal schief. Abhilfe: Definiere den Parametertyp explizit. Entweder im Objektinspektor, oder (wenn Du die Query zur Laufzeit zuweist)

markieren

Delphi-Quellcode:

Parameters.ParamByName('I').DataType := ftFloat;
Parameters.ParamByName('I').Value := 1.234;

Ist fest verdrahtet im Objektexplorer als ftFloat.

Hast Du es mal mit ftBCD statt float versucht?

Zitat von süden:

Ist fest verdrahtet im Objektexplorer als ftFloat.

Access oder SQL-Server?

Zitat:

markieren

Delphi-Quellcode:

dKost := FieldByName('intern').AsFloat;
...
Parameters.ParamByName('I').Value := dKost;

Welcher Datentyp ist dKost ? Jetzt sag nicht 'Double'

Hmm..

markieren

Delphi-Quellcode:

Post(TheCodeSchnipselThatMakesDieProbleme)
IF DB=Access then
  Append(TheBeispielAccessDB)
else
  Append(TheBeispielSchemaSkript)

Klar Double, wird ja als Float gelesen, und es funktioniert ja auch - bis auf die Kommaverschiebung.
Ich habe ja auch beides getestet, Float und String (mit '.' und mit ','.

Direkt in den SQL-Commandtext gehts ja.

Datenbanken: Für Access und SQL Server (ab 2005).

Habe ich da irgendwas nicht auf dem Schirm?

Wenn du mit Feldinhalten ein Problem hast dann darfst du nur dem MS SQL Management Studio vertrauen wenn du den Inhalt prüfen möchtest.
Ich wollt's nur mal gesagt haben weil wenn man sich nur auf ADO Komponenten verlässt die Ursachen nur schwer finden kann.

Eine weitere Quelle von Problemen sind verschiedene Datenbanken zur Design- und Runtime.
Sobald man in Delphi eine ADOQuery oder ADOCommand ändert wird im Hintergrund die ADOConnection geöffnet, der SQL-Text analysiert und daraus die Datentypen der Parameter abgeleitet.
Verweisst z.B. die Connection zur Designtime auf eine lokale Accessdatenbank während zur Laufzeit ein SQL Server verwendet wird passen die Parametertypen in manchen Fällen nicht so richtig zusammen.
Nach meinen Erfahrungen ist es besser zur Designtime eine SQL Server DB zuverwenden als eine Accessdatenbank.

Ich entwickle erstmal Datenbank unabhängig mit ADO,
dann teste ich mit Accsess + SQL Server (oder umgekehrt).

Hier habe ich zuerst mit Access getestet -> und bin nicht weiter gekommen.