try this query
SELECT
bytes,
bytes_priv,
bytes_bus,
hits,
hits_priv,
hits_bus,
bytes - ( bytes_priv + bytes_bus ),
hits - (hits_priv + hits_bus)
FROM url_cat_copy
WHERE
(bytes<>round(bytes_priv+bytes_bus,0))
or
(hits<>round(hits_priv + hits_bus,0))
i think its got something to do with the decimal
yes indeed. I will have to change my column definitions.
However, this behavior was not the case with 4.0.4. What seemed to be
going on with that branch was I could have an 11 digit number, with a
maximum of 9 digits behind the decimal. so numbers like 100493.43 were
fine. I'm assuming that this
In the last episode (Aug 05), Jeff Mathis said:
> after lokking at this, it appears that our float(11,9) columns cannot
> store an number larger than 100 or smaller than -100. the database is
> rounding the number! If we insert numbers -100 < x < 100, then its fine.
>
> is there a configuration
well, it appears that you are quite correct. changing the column
definition to float(11,3) for example now does the correct thing.
sean c peters wrote:
This is not a bug, its behaving exactly as it should. When you specify a
float(11,9) - you're saying an 11 digit number where 9 are after the de
after lokking at this, it appears that our float(11,9) columns cannot
store an number larger than 100 or smaller than -100. the database is
rounding the number! If we insert numbers -100 < x < 100, then its fine.
is there a configuration setting somewhere, or is this a known bug?
thanks
jeff
Jef
