I am trying to insert .shp (shape file) to MySQL using ogr2ogr but I am getting following error:
ERROR 1: MySQL error message:Too big scale 31 specified for column
'hght_lmt_m'. Maximum is 30. Description: ALTER TABLE
shapefiledatabase ADD COLUMN hght_lmt_m DOUBLE(33,31)
How to overcome this Limit ?
MySQL validates, and then ignores, the numbers in parentheses after DOUBLE in column definitions. It always uses IEEE 64-bit double precision floating point for DOUBLE. If that isn't enough precision for you, you're probably an astronomer.
So take away the (33,31) from your definition and you should be fine.
OGR's MySQL driver offers a flag that tries to preserve precision (see Layer Creation Options). Turn that flag off by setting -lco PRECISION=false on your ogr2ogr command.
Related
I'm using MySQL database and trying to change column precision. I need to restrict numbers to 2 zeros afrer comma. But after execute this code: $this->alterColumn(offer::tableName(), 'price', $this->double(8.2)->null()); column precision in database is empty.
Result:
What I'm doing wrong?
If you want to restrict the numbers to 2 decimal numbers you should use fixed-point type like DECIMAL(8, 2).
In migration:
$this->decimal(8, 2)
Floating point types like FLOAT and DOUBLE allows only limited ways to set precision. There is support for FLOAT(M, D) and DOUBLE(M, D) syntax in MySQL. But, it's pretty much just an alias and you will always end with 4-byte float or 8-byte double. See documentation
I'm using Perl to communicate floating point numbers with a mysql database. I perform a multiplication in perl:
$var = 0.001 * 3;
I then store this value in a mysql database in a column of type DOUBLE. I later retrieve the result, perform a further multiplication and addition to the number and store it back into the database
$previous_result_from_db += 0.001*1 + 0.001*0.5.
The result stored in the database should be 0.0045, but instead I get: 0.0045000000000000005. I'm trying to understand where the source of the imprecision is. Is it Perl or the database? What is the correct way to handle this kind of floating point interaction to avoid the imprecision?
Thanks!
"10.0 times 0.1 is hardly ever 1.0" -- Brian Kernighan, The Elements of Programming Style
It is a known limitation of FLOAT and DOUBLE that they are imprecise numeric data types. This is built into the design of the IEEE 754 format. It affects all programming languages that store floating-point numbers using this format.
MySQL documents this in this appendix: B.5.5.8 Problems with Floating-Point Values.
PHP documents this in Warning: Floating point precision.
If you want a scaled numeric data type in MySQL that avoids this rounding behavior, use DECIMAL.
Hi I am using the EXP() command in DB2 on a column of type float as so
select distinct 1 - power(0.9144,exp(beta - 0.1)) from mytable
where this all works fine until I introduce the exp() around (beta - 0.1). beta is a float and ranges between 3018.878989897931 and 12289.951602012534.
the error I am getting is
Arithmetic overflow or other arithmetic exception occurred.. SQLCODE=-802,SQLSTATE=22003,DRIVER=3.64.106
what could be the issue here?
Obviously, the issue here is your exceeding the maximum range representable by a 64-bit floating point number format, which is about +1.79769E+308.
If you do need to work with larger numbers, consider performing calculations in DECFLOAT(34) instead (if your DB2 version supports this data type).
In general, I have double values that I work with. I use them as double values and also as strings (in application code). I store them as Double in my MySQL database.
The problem I have is with trailing 0's. For example, the value I get is 10.60. This value gets truncated down to 10.6 which is not ok for me. I need that trailing 0.
I also need it to not add 0's. For example, if I got 10.60, it should not add 0's to be 10.600. I am not sure which data type fits my needs. It needs to be stored as the double value, but keep its trailing 0's, and not add any additional 0's.
Can anyone assist me in which data type to use?
I would store the double values in a double/real field only and not varchar so as to not lose any precision during conversion. Since the issue is only in application code, I would round them to the appropriate decimal places (using the ROUND() function) while retrieving from the database.
The round function sometime doesn't work very well. I have in my db a row like this:
field_1= 375
field_2= 0.65
field_3= 0.1
field_4= 11
So we know that: field_1*field_2*field_3*field_4 = 268.125 so if I round it to 2 decimals -> 268.13.
But in mysql I got 268.12 -> Select round(field_1*field_2*field_3*field_4) from my table -> 268.12
This situation just happens with these values, I tried with other numbers and no problem the round works.
Any workaround about it. I tried in mysql 4.1.22, and 5.1.44 and I get the same issue. I read in other forum http://bugs.mysql.com/bug.php?id=6251 that it is not a bug, they said that it depends on the C library implementation.
What data type are you using for those columns?
If you want exact precision then you should use NUMERIC or DECIMAL, not FLOAT, REAL, or DOUBLE.
From the manual:
The DECIMAL and NUMERIC types store exact numeric data values.
These types are used when it is important to preserve exact precision,
for example with monetary data.
If applicable you can use FLOOR()
If not applicable you will be better off handling this on the application side. I.e. do the entire calculation application side and then round, or just round application side.
SELECT (field_1*field_2*field_3*field_4) AS myCalculation FROM my table