I completely agree. For now, I'm afraid you'll have to use decimal or some
other datatype. You could file a bug on the server as this is definitely
something we can fix.
> > Have a look at this link (if you have not already).
> > http://dev.mysql.com/doc/refman/5.1/en/problems-with-float.html
> Thanks. I've seen it before..
> I don't think it's relevant (but feel free to correct me):
> a) In the case we're discussing, the user does not have control over
> the query. It's built for him. (... And the query builder has no
> provision for setting a precision to use when comparing floats. It
> could in theory do as the example you link to, but it doesn't..)
> b) MySQL stores floating point numbers in one precision. It compares
> numbers using this precision. But it returns results with another
> (lower) precision.
> This issue would not need a workaround in each SELECT, if it was
> solved in the server so that numbers were either returned with a
> higher precision (enough to match the record later with a SELECT),
> or numbers were stored with a lower precision (in practice we'd be
> rounding numbers on INSERT rather than on SELECT).
> Solving the problem in the server would be consistent with what
> other professional database server products do, as far as I can see:
> INSERT: 0.666666666666667 0.6666666666666666
> (MySQL) SELECT *: 0.666666666666667 0.666666666666667
> (MS SQL) SELECT *: 0.66666666666666696 0.66666666666666663
> (MySQL) WHERE: 1 record 0 records
> (MS SQL) WHERE: 1 record 1 record
> (For the WHERE clauses I used the values I got from the server in
> the corresponding SELECT (on the same server type). For data types
> on MS SQL, I used the conversion table from
> Ho hum..
> MySQL on .NET Mailing List
> For list archives: http://lists.mysql.com/dotnet
> To unsubscribe: http://lists.mysql.com/dotnet?unsub=1