When I save data byte[] in SQL Server the value change and add 0x0 in the first of value
the correct value (0xFFD8FFE000104A46)
the incorrect value (0x0FFD8FFE000104A46494600010102004C)
0xF and 0x0F are the same number, both are hexadecimal notations of number 15 decimal. A byte contains two hexadecimal 'digits'. If the left most digit is 0, it doesn't affect the value, just like zero-hundred and fifteen is the same as fifteen. The notation with the leading 0 just prints all the bytes, the one without strips the leading zeros.
Where the 494600010102004C part is coming from I don't know.
Related
Please explain why
select convert(int,'1') = 1
but
select convert(int,
convert(varbinary(MAX),'1')) = 49
Convert to varbinary without a style parameter defined translates each ASCII character in input string to a binary byte. That is why the input string '1' first gets mapped to the ASCII code 49, after which the outer convert returns the integer value 49.
Because convert(varbinary(MAX),'1') is binary 0x31 which is integer 49.
By using varbinary you are essentially converting the ascii representation of "1" to the actual binary digits which represent it.
You will get the same result using select ascii('1').
In the same way select convert(varbinary(1),'A') = 0x41 which in base 10 is 65, which is the ascii value for A
I was checking if DB pads spaces in a column if the inserted string has fewer characters than the designated length of the column. Example:
lets say size of <column1> is 10 but the value entered is abc - then is it abc_______ which the DB stores where _ represents spaces?
I am asking because I used LTRIM-RTRIM while INSERTing the values and on again fetching the value in the very next minute I got the result as abc_______.
You are using the CHAR or CHARACTER datatype for the column. The CHAR or CHARACTER datatype is a fixed length datatype and is padded with space at the end of the value to fill the column size.
You can use VARCHAR to avoid the padding with spaces at the end of the values.
Note: Make sure you are using CHARACTER_LENGTH on CHARACTER columns to get the correct character length (without padding spaces). The result of LENGTH also includes the padding spaces.
demo on dbfiddle.uk
I was checking out the difference between char vs varchar2 from google. I came across a word LEADING LENGTH in this link . THERE it was written that
Suppose you store the string ‘ORATABLE’ in a CHAR(20) field and a VARCHAR2(20) field. The CHAR field will use 22 bytes (2 bytes for leading length). The VARCHAR2 field will use 10 bytes only (8 for the string, 2 bytes for leading length).
Q1:How does the char field will use 22 bytes if the string is of 8 characters if (1 byte = 1 char)?
Q2 What is the LEADING LENGTH ? why it does occupy 2 bytes?
The CHAR() datatype pads the string with characters. So, for 'ORATABLE', it looks like:
'ORATABLE '
12345678901234567890
The "leading length" are two bytes at the beginning that specify the length of the string. Two bytes are needed because one byte is not enough. Two bytes allow lengths up to 65,535 units; one byte would only allow lengths up to 255.
The important point both CHAR() and VARCHAR2() use the same internal format, so there is little reason to sue CHAR(). Personally, I would only use it for fixed-length codes, such as ISO country codes or US social security numbers.
I am calling
FORMAT(myNum, '#,###') AS myNum
Which works for 123456789 as the output is 123,456,789
Also works for negative numbers
However, 0 is showing up as a blank field.
How do I get 0 to show up as 0? I am also curious as to why 0 is being removed as the query without the format shows 0 in that column's field when there should be a 0.
Note: I do not need any decimals and would prefer to use the above code if at all possible.
If you want to display the 0, if it is zero, you should use:
FORMAT(myNum, '#,###0') AS myNum
According to this Reference:
https://msdn.microsoft.com/en-us/library/ee634206.aspx
0 (zero character)
Digit placeholder. Displays a digit or a zero. If the expression has a digit in the position where the zero appears in the format string, displays the digit; otherwise, displays a zero in that position.
If the number has fewer digits than there are zeros (on either side of the decimal) in the format expression, displays leading or trailing zeros. If the number has more digits to the right of the decimal separator than there are zeros to the right of the decimal separator in the format expression, rounds the number to as many decimal places as there are zeros. If the number has more digits to the left of the decimal separator than there are zeros to the left of the decimal separator in the format expression, displays the extra digits without modification.
# Digit placeholder:
Displays a digit or nothing. If the expression has a digit in the position where the # character appears in the format string, displays the digit; otherwise, displays nothing in that position.
This symbol works like the 0 digit placeholder, except that leading and trailing zeros aren't displayed if the number has fewer digits than there are # characters on either side of the decimal separator in the format expression.
I have a question about the format of numbers REAL.
I have a column with this type and after I insert 8 numbers for this column, it doesn't let me to save.
Example: 11406760
When I try with a 7 digit numbers like 1140676, it lets me to save the data.
Any idea why this happens?
If I read this MSDN page correctly, REAL is a synonym for FLOAT(24), which has a precision of 7 digits.
This means that while a column of this type does support values up to about 10^38, it only keeps about 7 most significant digits of that value. So for an 8 digit number, the final digit may not be stored correctly.
Do you really need a REAL (=floating point) value for this column (maybe check out decimal), or rather some integer type?