do with the decimal type..
try googling or search in the manual book
i've red somewhere, that a decimal number in computer never as exact
as what they have meant..
HTH
Leo
On Tue, 24 Aug 2004 08:41:47 +0200, Martin Rytz <[EMAIL PROTECTED]> wrote:
> Good Morning Community!
>
> I have
Good Morning Community!
I have a problem with 4.1.3 that I not had with 4.0.20.
Here is my table:
CREATE TABLE url_cat_copy (
id int(11) NOT NULL auto_increment,
url varchar(100) default NULL,
domain varchar(100) default NULL,
bytes bigint(20) default NULL,
hits bigint(20) default
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
after upgrading from 4.0.4 to 4.1.3, we noticed that some of our
float(11,9) columns refused to store anything other than the numer -100
or the number 100, even though the insert or update sql clearly
specifies other numbers. We've tried dropping the table and reloading
the data -- same problem