I have a database and a bigint column type. Everytime I insert value to this column I always got the wrong number. for example, I insert value "198705122006041001" and it always insert this value "2147483647".
I use laravel for my project, if I use eloquent to display the bigint it wont display correctly but if I use PDO manually, it will display correctly.
PHP has no bigint data type, it overwflows and uses int.max instead. You have to represent bigints as string or float. Be aware, that float is not precise and can lead to surprises.
Do the mathematical transformations in MySQL and don't forget to cast to bigint when necessary.
You should check this again, because it's definitely int, but not bigint. 2147483647 is a maximum possible value for signed int
See https://laracasts.com/discuss/channels/eloquent/fbid-bigint-with-model-and-eloquent. A Laravel user had the same problem, and eventually had to cast the result to a string.
Another user comment pointed out that XAMPP provides only a 32-bit PHP binary, which limits the size of a PHP integer.
Check your PHP integer size with this code:
<?php
echo "Integer size can be determined using the constant PHP_INT_SIZE="
. (PHP_INT_SIZE * 8)
. " bits, maximum value using the constant PHP_INT_MAX="
. PHP_INT_MAX;
See also http://php.net/manual/en/language.types.integer.php
Install https://laravel.com/docs/5.3/homestead and get a 64-bit PHP binary.
Related
When I tried to fill in a big number, error. How to add the maximum limit of INT?
UPDATE `test`.`number` SET `idNumber` = '36552124313028521236524313028' WHERE (`idNumber` = '365521');
You could try use a BigInt
If you want a number larger than the largest 64-bit unsigned integer 18,446,744,073,709,551,615 then you will need to store it as a varchar or some other Text form
refer to the MySQL data types for further info
It depends on how the column is to be used. For calculations or auto_increment attribute, numerics should be used. As you say you would like to add a maximum limit, by ADD I suppose you would like to define a length value to your liking. However, the whole number types such as small int, int, big int have a predefined maximum range , which can not be changed.（MySQL 8.0 users may try the check option, which is ignored in previous versions） If you need to define the limit for the whole number, there is a workaround by using decimal(n,0) to make the number always appear as a whole number.
For identifiers which do not require numerical calculations, varchar is generally acknowledged for strings that have a dynamic range, and char is more suitable for those having a static length,such as province acronym e.g AZ (Arizona) AR (Arkansas) CA (California). At the first glance of your idNumber column, I reckon it's better used for it's string's nature rather than numerics.
Last but not least. Please refrain from using a varchar for string-looking values that are prone to calculations,such as IP ADDRESS. It appears as a string in its dotted format, but deep inside it has an inherent nature of numerics. For instance, IPV4 has a range from 0.0.0.0 to 255.255.255.255 , which can be treated as a formula of (256 * 256 * 256 * 256) . Thus it is a perfect fit for the unsigned integer type in terms of length and can be calculated when necessary. To display it in its dotted format , use the inet_ntoa() function. e.g select inet_ntoa(3232235777);
I want to insert/update decimal number to mysql. But everytime I did. It return the round number or truncate dot number. I tried change the datatype of lv_pay and lv_dis either to decimal and double but still the result.
MySQL
update settings_price_pay set lv_pay='3.2',lv_dis='0' where pset='1' and cate='161a5954c2e7713417906c523204a2be' and ltype='p_rhi'
PHPMyadmin
First:
The data type of those numeric fields should be DECIMAL(12,2) or something similar, declaring that you use a picture of S#########9.99. Sign, ten digits, point, two digits.
Second:
Don't put your numbers in 'quotes'. If you do, MySQL first coerces them to IEEE 64-bit numbers, then to whatever datatype you have for your columns. Say this:
set lv_pay=3.2, lv_dis=0
Notice that MySQL ignores the numbers in parentheses in DOUBLE(11,2) and simply uses a 64-bit IEEE floating point number. (It honors those numbers when you declare a DECIMAL(12,2) data type.)
Got an answer, just for novice like me. Change the 'length/value' of the row (in my case) from (11,0) into (11,2). Found it accidentally.
My mysql version is 5.7.14
I have 1 table with two column
1). price_val_float with float data type
2). price_val_double with double data type
Table structure
CREATE TABLE test (
price_val_float FLOAT(6,2),
price_val_double DOUBLE(6,2)
);
Same value in both column
INSERT INTO test VALUES
(78.59, 78.59),
(78.60, 78.60),
(78.61, 78.61);
Now I set one variable as follow
SET #priceValue=78.6;
Now I want to get all record from test table where price_val_float >= #priceValue;
SELECT price_val_float FROM test WHERE price_val_float>= #priceValue;
above query return only 78.61
But if I run same query of price_val_double column
SELECT price_val_double FROM test WHERE price_val_double>= #priceValue;
This return
78.60
78.61
I am not getting why mysql return different result as only data type is different.
Does anyone knows about this ?
Here is Fiddle for testing
Thanks in advance.
This might sound strange to say but this is because decimal numbers are approximates values. This is an issue across all programming due to the nature of storing large numbers. Even the mysql documentation calls these "approximate" values:
https://dev.mysql.com/doc/refman/5.5/en/floating-point-types.html
For example: MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.
This is explained in the mysql documentation here:
https://dev.mysql.com/doc/refman/5.5/en/problems-with-float.html
Or as an additional case explained in Python here:
https://docs.python.org/2/tutorial/floatingpoint.html
The way to get around this is identify the precision you want and store the value as an integer.
Float is a single precision and Double is for double precision that why your getting the difference.
This is happening because the difference between the numbers shows up around the tenth decimal or so, depending on factors such as computer architecture or the compiler version or optimization level. For example, different CPUs may evaluate floating-point numbers differently.
You need to use DECIMAL data type for more accurate results. Also check this for more details
That is because Float point values are not stored as exact values. If you need exact value you can use Decimal data type. You can read about it here
I have a MySQL column "phone" , and when data comes from my php form, if there's a zero at the beginning, it will disappear in the table, for example :
"06719823" becomes "6719823"
I first though it was a problem from php, cause I'm using mysql_real_escape_string(), but then I tried to modify the SQL field directly on phpmyadmin, and I can't add a first 0, it always delete it.
Colonne Type Interclassement Attributs Null Défaut Extra
phone int(10) Oui NULL
What's wrong ? Should I assign an "interclassement" utf8_general_ci ?
Change your column type to char(10) for 10 digit phone numbers.
If the column type is int (integer), the number will be internally represented as an integer, meaning "first 0s" won't be stored, as they hold no meaning for integers.
Since what you are actually trying to store has meaning as a sequence of characters, and not as a quantity, it would make more sense to store it as a char(n), for n-digit sequences, or as a varchar for sequences whose size varies a lot.
Make your phone attribute as Varchar or Text to avoid this.
Phone numbers can at time also contain brackets and hyphens plus you can avoid your problem as well.
Change your data type. Int Data type will not store the starting 0's.
You can try as suggested above char or varchar
Integers : 06719823 = 6719823 = 0006719823
Save the phone as varchar if you would like to retain zeros in the begining
I need to create a good/neutral/bad field. which one would be the more understandable/correct way.
A binary field with null (1=good, null=neutral, 0=bad)
An int (1=good, 2=neutral, 3=bad)
An enum (good, neutral, bad)
Any other
It's only and informative field and I will not need to search by this.
NULL values should be reserved for either:
unknown values; or
not-applicable values;
neither of which is the case here.
I would simply store a CHAR value myself, one of the set {'G','N','B'}. That's probably the easiest solution and takes up little space while still providing mnemonic value (easily converting 'G' to 'Good' for example).
If you're less concerned about space, then you could even store them as varchar(7) or equivalent and store the actual values {'Good','Neutral','Bad'} so that no translation at all would be needed in your select statements (assuming those are the actual values you will be printing).
In Mysql you ought to be using an enum type. You can pick any names you like without worrying about space, because Mysql stores the data as a short integer. See 10.4.4. The ENUM Type in the documentation.