also ich verwende in meiner DB den Typ Float. Jetzt lasse ich den Anwender eine Fließkommazahl eingeben, und speichere sie dann ab in dieses Feld. Wenn ich sie dann wieder auslese, wird aus z. b. 12,40 12,39889889789 ungefähr. An Delphi kann es nicht direkt liegen, denn wenn ich showmessage(floattostr(strtofloat('12,40'))) mache, bleibt er immer noch bei 12,40. Abspeichern tue ich über Parameter, also so: Query.Params[0].asfloat:=zahl; Auslesen tue ich mit Query.fieldbyname('zahl').asstring, und gebe das dann in einem Textfeld aus.

Ich bin mir nicht sicher, muß das so sein?

3 Fragen :

1. wie ist das Feld in der DB genau definiert (Größe, Nachkommastellen) ?
2. was zeigt ein Admin Tool wie IBExpert an ?
3. DECIMAL schon getestet ? Ich verwende immer das und habe solche Effekte noch nie gehhabt.

Übrigens ist dein showmessage "Test" wirklich kaum nützlich.

Stop ! Noch 2 Fragen : Warum verwendest Du das veraltete Query und kein Dataset ? SQL-Dialekt ?

1. der firebird-typ heißt auch float, wenn ich mich nicht irre (müsste nochmal zuhause nachschauen)
Größe und Nachkommastellen muß man da nicht angeben.
3. nein noch nicht. Ich möchte aber den Anwender nicht festlegen auf Anzahl Vor/Nachkommastellen

SQL-Dialekt ist 3. Ich verwende immer Querys und bisher nie Probleme damit gehabt.

Hi,

wenn Du den Typ Float verwendest, liegt das daran, wie solche Zahlen abgespeichert werden (ist immer so, nicht nur bei IB, sondern in allen Programmiersprachen, DB,....). Wenn Du "genaue" Zahlen speichern willst, nimm Decimal oder Numeric und gut ist! In Delphi steht der Typ Currency (bis zu 4 Nachkommastellen, die aber ganz genau) zur Verfügung, um diese Effekte zu vermeiden.

GRüße
Lemmy

gut danke, ich werde das nachher testen. @hansa, wo du es ansprichst: wo sollen Querys veraltet sein? Wo schreibst du denn deine SQL-Befehle rein? Ich verwende aber nur D7 Prof. Veraltet vielleicht, aber ausgereift denke ich.

Das fing mit der BDE an, die seit ca. 5 Jahren nicht mehr weiterentwickelt wird. Um den Leuten den Umstieg schmackhaft zu machen, die eben nur die BDE-TQuery usw. kannten wurde was ähnliches in Interbase auch eingebaut. Und ehrlich gesagt, ich glaube kaum, daß bei eventuellen vorhandenen Bugs daran noch was gemacht wird. Also -> vergessen und schon gar nicht damit anfangen. Was ich darüber gelesen/gehört habe, das hat mir jedenfalls völlig gereicht. Ach ja, wie das gemacht wird, mit Dataset ?



Das wäre jetzt für eine Adresse, sofern die NR eindeutig ist. SelectSQL ist ein TString. Da kann man also auch mit Add usw. arbeiten und sich so auch kompliziertere SQL-Statements zusammenbauen.

Allerdings frage ich mich gerade, wie das mit IBTable überhaupt geht ? Ich wills aber auch gar nicht wissen. Das da ist mir einfach genug.

Na wie gesagt, nie irgendwelche Probleme damit gehabt... insofern sehe ich keinen grund umzusteigen.

Das stimmt : Hauptsache es geht und keiner weiß warum, als umgekehrt. Es gibt da nur ein kleines Problem : was, wenn das Programm mit den auf Interbase umgefriemelten "BDE-kompatiplen" Komponenten immer größer wird und es heißt irgendwann : "... sind nicht mehr im Lieferumfang enthalten, weil sowieso keiner mehr damit arbeitet und sie seit Delphi xxx sowieso nicht mehr angepaßt wurden. Ein Vorteil davon ist auch, daß Delphi nun doppelt so schnell startet." Dann viel Vergnügen mit nagelneuem Delphi und dem Löschen der TQueries, neuanlegen der Datasets, im OI Datenbank usw. einstellen. Natürlich Source unnötigerweise umbauen usw. Solche unnötigen Arbeiten trotz massig Vorwarnungen wird dir keiner bezahlen. Und es betrifft ja auch ganz normale DBEdits. Bei mir müßte hunderten DB-Edits neu gesagt werden, wo die Daten herkommen.

Ich habe übrigens nach dem TQuery gefragt, weil ich über ähnliche Sachen mit dem Runden oder zu ungenauen Ergebnissen gelesen habe (mit Query-Beteiligung). Es würde mich nicht wundern, wenn es tatsächlich daran liegt oder später so ein Fehler auftaucht.

"Solche unnötigen Arbeiten trotz massig Vorwarnungen wird dir keiner bezahlen. "

arbeiten mit unausgereiften neuen Komponenten aber auch nicht
Zukunftskompatibilität gibt es nicht.

Amiga-Fan hat folgendes geschrieben:

..arbeiten mit unausgereiften neuen Komponenten aber auch nicht.

Äh, immer noch nichts kapiert ? Es gibt wieder mehrere Möglichkeiten : Du bist froh und glücklich, daß das Programm nach endlosen Anläufen jetzt mit TQuery geht. Schön, aber keiner der sich auskennt würde es kaufen weil es nicht zukunftssicher ist und auf uralten Konzepten basiert, die seit längerem nicht mehr weiterverfolgt werden. Es sei denn, Du kannst sagen, daß es in absehbarer Zeit umgestellt wird. Bei einem solchen Anfängerverhalten ist davon aber nicht auszugehen, daß es gelingt. Zumal .NET vor der Tür steht.

Und bei einem, der denkt er wisse was los ist und in Richtung BDE geht (als Profi), dem glaubt man schon mal von vorneherein gar nichts. Zumal er noch behauptet, nicht-BDE Komponenten seien "unausgereift". Das ist nun gänzlich unausgereift. Überlege das ganze lieber nochmals, es sei denn das erste gilt und soll sich auch in Zukunft nicht ändern.

keine Ahnung, wovon du redest. Von etlichen Anläufen kann überhaupt keine Rede sein. Schon mal daran gedacht, Prediger zu werden? Nur Spass.

Zukunftssicher ist gar nichts. Der Spruch mit dem unausgereift war eher allgemein bezogen, ich wusste das das kommt...

Nichts für ungut, danke für deine Hilfe Lemmy hat mir schon geholfen.