Recently, my own program in the call to MySQL stored procedures to the smallint type variable, always appear out of the range value of the error, just beginning with the C-value conversion mode of bits conversion thinking to think, always feel no problem, Because my number is really in the 16-bit binary number can be saved, but later found that the original MySQL is not in accordance with this binary conversion method.
The range of values for each of the MySQL integer types is attached first:
bigint
Integer data (all numbers) from -2^63 (-9223372036854775808) to 2^63-1 (9223372036854775807). The storage size is 8 bytes.
P.S. bigint already has length, in MySQL build table length, just used to display the number of digits
int
Integer data (all numbers) from -2^31 (-2,147,483,648) to 2^31–1 (2,147,483,647). The storage size is 4 bytes. The SQL-92 synonymous word for int is integer.
smallint
Integer data from -2^15 (-32,768) to 2^15–1 (32,767). The storage size is 2 bytes.
tinyint
Integer data from 0 to 255. The storage size is 1 bytes.
Because the stored procedure to be called is primarily to implement the insert operation, and the table field corresponding to a variable of type smallint in this stored procedure is an unsigned smallint, because the MySQL stored procedure is not unsigned this type, So it had to be received with smallint when the stored procedure was accepted, and it was assumed that MySQL would automatically convert the signed number to unsigned numbers as in the C language.
But that's not true, when I pass in parameter 64000 (not within signed bigint within unsigned bigint), MySQL will prompt for an error out of range value, meaning that it is out of range. After constant testing, I found that MySQL would not automatically convert the signed number to an unsigned number in the same way as the usual programming language mechanism, and when it is judged that you are not in the signed number (here is 32768-32767) or unsigned (0-65535), it determines that you are an illegal number, is out of range and then prompts for an error; When you use an unsigned number, if you pass in a negative number, you are considered to be an illegal number (the pro-test is this), and then the error is also indicated.
Workaround:
Since the stored procedure does not have an unsigned type, we can use a wide range of numbers to receive the incoming values, such as I have changed the smallint type to int, and it will work.
Personal Understanding:
I personally think that MySQL in the numerical aspect does not pay particular attention to the concept of type, but only concerned about the scope, we set the type, is actually set the scope, when we pass a number, if within this range, we will assume that this type. Of course, this is my personal opinion, just to facilitate understanding. If there is any problem, I hope you will make more suggestions.
Problems related to signed numbers and unsigned numbers under MySQL