I'm running an insert using PDO parameter values, and it's working fine, but I'm getting a lot of zeroes where I should have 0.65, 0.7, etc.
The issue is, its inserting into a decimal field and the sql insert is
count(*) / :value
In this case, :value is '1' so instead of dividing the count by 1, I want to divide by 1.0 specifically.
Can I append a decimal and zero to my parameter?
perhaps different approach... ALTER TABLE xxx ALTER COLUMN YYY theColumnName decimal(4,2) or whatever you need, then it will not add zeros after second decimal place
Related
I have two columns on my database, sickleave and vacationleave. It has to be a decimal but for some reason I only get the whole number. For example, I input 1.50, when I press update I get the value 2. I tried setting the column type to decimal but I still get the same result.
Here's my database schema:
From the mysql documentation:
The declaration syntax for a DECIMAL column is DECIMAL(M,D). The ranges of values for the arguments are as follows:
M is the maximum number of digits (the precision). It has a range of 1 to 65.
D is the number of digits to the right of the decimal point (the
scale). It has a range of 0 to 30 and must be no larger than M.
So in your case: hit change button there and in the Length/value column there should be: 11,2 with no parentheses or anything else when you hit save
In case you want to do it manually there's a discussion of it here: MySQL - How do I update the decimal column to allow more digits?
And here's the alter: ALTER TABLE YourTableName MODIFY COLUMN column_name DECIMAL(11,2);
Tried altering it manually using:
ALTER TABLE YourTableName MODIFY COLUMN price DECIMAL(4,2);
Thanks #user3647971
Here is my table:
Let us suppose I want my account balance to be:
0.4729472846758294728572
So I tried to set it to it but it keeps cutting it off and rounding up.
How can I stop this behavior?
FLOAT values are approximate:
The FLOAT and DOUBLE types represent approximate numeric data values.
If you need arbitrary precision you can use a DECIMAL column instead, e.g. DECIMAL(25, 20). In this case you'll get 5 digits before the decimal and 20 after.
MySQL permits a nonstandard syntax: FLOAT(M,D) or REAL(M,D) or DOUBLE PRECISION(M,D). Here, (M,D) means than values can be stored with up to M digits in total, of which D digits may be after the decimal point. For example, a column defined as FLOAT(7,4) will look like -999.9999 when displayed. MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.
see here:https://dev.mysql.com/doc/refman/5.7/en/floating-point-types.html,
http://code.rohitink.com/2013/06/12/mysql-integer-float-decimal-data-types-differences/
We currently have a table row set to INT and a php script that adds the value of 5000 every 60 seconds(cron). We now need the ability include a decimal point.
If we change the addition value of 5000 to say 5000.19, would this work with INT? or do we need to change the row to Decimal?
I hope that makes sense.
Breakdown:
Current Setup
Start Number: 12500 (INT)
Increase Amount: +5000 (No decimal)
We now need it to work with decimals:
Start Number: 12500
Increase Amount: +5000.19 (with decimal)
You could just change the column to "text" or "varchar" as a lazy work around, it will work fine in most circumstances
Yes, you will need to convert the column's data type. INT columns store only integer numbers.
alter table my_table modify time_value decimal(18,4);
Make sure you choose the correct precision and scale values for the decimal type.
I have a table with a current structure as follows:
Currently this is populated as follows:
The data stored for product value is a decimal value
and the end digits are cut off once it is inserted into the database.
I have tried changing the table structure as follows:
However this only leads to the following:
As you can see all values have a .00 appended if none exists, however I want to
store all these values with no decimal places. Except the product value.
How can I do this?
The trouble is you are converting a decimal (float / double) to an integer, so the value is simply truncated (decimal values are chopped off).
If you really don't want to use floats (decimal values) in the database you can use this hack work around will work:
Multiply the number by 100 before inserting it, and then be sure to divide it by 100 when you use the data. This will allow you to maintain 2 decimal points while using integer storage.
Thus, 2.4 would be stored as 240, 53 would be 5300, 20.74 becomes 2074 etc...
I want to note that this is not an ideal solution, but rather a hack.
I highly recommend what the other users suggested in the comments: storing the decimal value (as you have) and formatting it when presenting it.
--- In addition ---
Your real problem appears to be with the way the database is setup.
Each of those values should have their own field since they will be repeated for each product.
I have one PHP script inserting rows in a MySQL database. Each row has a field 'created_at' which is filled with the value of the PHP function microtime(true), and inserted as a double. (microtime because I need something more precise than to the second)
I have another PHP script that selects rows based on that created_at field.
When I go ahead and select like this:
SELECT * FROM `ms_voltage` WHERE created_at > 1302775523.51878
I receive a resultset with, as the first row, the row with exactly that value for created_at.
This occurs from within my PHP script and from within PhpMyAdmin when manually doing the query. But not always, not for every value. Just once and a while really.
How is this possible? I didn't ask for greater than/equals, I want strictly greater than.
Am I overlooking something type-related perhaps?
Yeah, floating point arithmetic can do that sometimes. To understand why, it's helpful to realize that just as not all numbers can be accurately represented in base 10, not all numbers can be accurately represented in base 2 either.
For example, "1/3" may be written in base 10 as 0.33333 or 0.33334. Neither is really "correct"; they're just the best we can do. A "DOUBLE" in base 10 might be 0.3333333333 or 0.3333333334, which is double the digits, yet still not "correct".
The best options are to either use a DECIMAL value, or use an INT value (and multiply your actual values by, say, 10000 or 100000 in order to get the decimal digits you care about into that int).
The DOUBLE type represent only approximate numeric data values. Try to use the DECIMAL type.
Is your column floating point? Calling microtime with true gives you a float, and that looks like a float, which will have digits after the .51878 that you don't see, so those digits make the stored value greater than the value you have in your query.
Unless you really need the float I'd convert the string result to an int, or even two columns for seconds and useconds. Then you can use > or < on known values without worrying about the imprecision of the floating point value.