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
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);
The text data I have for a column in database in an enterprise application (uses hibernate) is huge and after increasing varchar size to a specific number, I don't have any other choice but to change the datatype to text. Can anyone help me understand how it may affect my application. Do I need to take care of anything else or just changing the datatype works ?
You should use TEXT. Although, that's the same thing as VARCHAR:
If the declared type of the column contains any of the strings "CHAR",
"CLOB", or "TEXT" then that column has TEXT affinity. Notice that the
type VARCHAR contains the string "CHAR" and is thus assigned TEXT
affinity
Also note
Note that numeric arguments in parentheses that following the type
name (ex: "VARCHAR(255)") are ignored by SQLite - SQLite does not
impose any length restrictions (other than the large global
SQLITE_MAX_LENGTH limit) on the length of strings, BLOBs or numeric
values.
Your application work fine with datatype text.You don't need to take care of any thing
if you want to be sure, create backup database first just in case,
or at least backup/duplicate table you were going to make changes
for me I also prefer varchar than text
because varchar used to be using smaller memory than text
ex : address (100) , records only using 80 character, will be saved as 80 character in varchar
while in text , will be saved as 100 character
I am making a small project in which I am using mysql for my database, in which i need to input phone numbers with std codes.
The problem is in inserting proper std codes.
Suppose the std code is 0123 but while running the query it is only inserting 123.
If it is 0275, it is only inserting 275.
but if it is 2210 it is properly inserting 2210
i tried making it "int", "bigint", "varchar" but all in vain..
plz sggst to solve it..
Try with this.It should work varchar(5)
I usually store phone numbers as a BIGINT in E164 format.
E164 never start with a 0, with the first few digits being the country code.
+441234567890
+44 (0)1234 567890
01234 567890
etc. would be stored as 441234567890.
But my suggestion is you can use a varchar for a telephone number.
You do not need an int because you are not going to perform arithmetic
on the numbers.
VARCHAR will work in your case.
The only thing you have to make sure is, while inserting the data, you're traeting the data as string, that is enclosing with single quotes. Otherwise, you will again end up losing leading zeroes, doesn't matter you have VARCHAR as the datatype
INSERT INTO tab VALUES('0123');
I have to store isdCodes which is in format 0091 001 009751 009665 etc. in the database, the initial will basically start from zero. i tried using int as datatype with unsigned attribute but it does not seems to work. which datatype is suitable for storing this type of value?
Does not work since IDD prefix is in most cases 00 but not always. It starts in most cases with 0 but not always.
Since the number of leading zeros matter, (i.e., 0091 ≠ 091), I would go for a varchar in this case.
If you really want to use some numeric type, I guess you could prepend a 1 in front of the number to keep the zeros, but it would be a bit of a hack.
I would use some varchar for that since ISD codes are not something you want to "calculate with" and are a sequence of digits rather than a whole number itself. The leading 0 and 00 thing shows that very good.
Edit
Just saw that IDD prefixes like 8~10 exist. So there is no way to use a number-like datatype. You have to use something like varchar or similar if you want be able to store any ISD code.
You can use ZEROFILL, i.e.:
CREATE TABLE test (value int zerofill);
INSERT INTO test values(1), (20), (515);
I haven't used CHAR much in the past as I seemed to use VARCHAR too much; I'm trying to use CHAR when appropriate lately & from what I understand you use it when the data is all the same length in that certain column (else it is padded with spaces).
Because all the data is supposed to be the same length I was wondering can a CHAR field be NULL or an empty string? Such for cases when that specific field doesn't have a value whilst others do.
The answer to your question(s) is Yes.
Yes, the CHAR type can be NULLable. I believe every column type can allow for NULL.
Yes, the CHAR type can be an empty string. The DB will not see an empty string as any different from any other string. I wouldn't suggest ever using empty string though because, in almost every case, an empty string (lack of ANY characters) is trying to represent a lack of data, which is what NULL is for.
If you want to know more specific details around the difference of CHAR vs. VARCHAR in MySQL specifically...
MySQL 5.0 Reference - The CHAR and VARCHAR Types
Yes, both NULL and empty string can be used. The data doesn't have to be the same length in the column, as you noted, anything smaller is just padded with spaces to fill the column.