I have Two SQL Query Both Return
select round(convert(float,'24367.723'),2)
Result:24367.72
Second:
select convert(varchar(20),round(convert(float,'24367.723'),2))
Result:24367.7
Why the Second Query Return exclude the last digit after converting to varchar
Thanks in Advance
By not specifying a style parameter to the convert function you get the default style (0).
i.e. it is equivalent to doing
select convert(varchar(20),round(convert(float,'24367.723'),2), 0)
The default style for converting from float to varchar displays a maximum of 6 digits.
When working with a float the STR() function usually gives better results according to MSDN as you've more control.
E.g.
select str(convert(float,'24367.723'),8, 2)
Dont use floats, use exact numberics. Something like this
convert(varchar(20), convert(numeric(20,2), '24367.72'))
Related
Can anyone help me to fix this issue please?
I'm getting an error while trying to convert this to BIGINT:
SELECT CONVERT(BIGINT, '10472553255347451137')
Thanks
Well, your number simply is to large for a bigint. A bigint's maximum is 9223372036854775807, see the documentation.
And as 9223372036854775807 < 10472553255347451137, there's no way to convert 10472553255347451137 to a bigint.
And BTW, do not post images of error messages. Paste the text into the post's text.
If you query for the length of the number, it's 20. Therefore, you may use Numeric(20, 0) to store the value.
Length
SELECT len('10472553255347451137')
20
Select converted value
SELECT CONVERT(numeric(20, 0), '10472553255347451137')
10472553255347451137
I am using code like this in my SELECT statement:
CAST(HASHBYTES(N'SHA1', Bla) AS NVARCHAR(MAX)) AS hashed_bla
and end-up with "chinese"/UTF encoded characters in the ssms grid but also in upstream apps. Is there a way to change this? Does this have to do with the collation? Thanks!
What you have is working as expected. Take the following example:
SELECT HASHBYTES('SHA1','B8187F0D-5DBA-4D43-95FC-CD5A009DB98C');
This returns the varbinary value 0xA04B9CB18A2DC4BC08B83FCCE48A0AF1A1390756. You are then converting that value to an nvarchar, so get a result like N'䮠놜ⶊ별레찿諤㦡嘇' (on my collation). For an varbinary each 4 characters represents a single character. So, for the above A04B is the first character (which is N'䮠').
It appears what you are after is an varchar representing a varbinary value (you don't need an nvarchar here, as there will be no unicode characters). To do so, you need to use CONVERT and a style code. For the example I gave above that would be:
SELECT CONVERT(varchar(100),HASHBYTES('SHA1','B8187F0D-5DBA-4D43-95FC-CD5A009DB98C'),1);
Which returns the varchar value '0xA04B9CB18A2DC4BC08B83FCCE48A0AF1A1390756'. If you don't want the '0x' at the start, use style code 2, rather than 1.
How would I take apart a column that contains string:
92873-987dsfkj80-2002-04-11
20392-208kj48384-2008-01-04
Data would look like this:
Filename Yes/No Key
Abidabo Yes 92873-987dsfkj80-2002-04-11
Bibiboo No 20392-208kj48384-2008-01-04
Want it to look like this:
Filename Yes/No Key
Abidabo Yes 92873-987dsfkj80-20020411
Bibiboo No 20392-208kj48384-20080104
whereby I would like to concat the dates in the end as 20020411 and 20080104. From the right side, the information is the same always. From the left it is not, otherwise I could have concatenated it. It is not an import issue.
As mentioned in the comments already, storing data like this is a bad idea. However, you can obtain the dates from those strings by using a RIGHT function like so:
SELECT RIGHT('20392-208kj48384-2008-01-04', 10)
Output:
2008-01-04
Depending on the SQLSERVER version you are using, you can use STRING_SPLIT which requieres COMPATIBILITY_LEVEL 130. You can also build your own User Defined Function to split the contents of a field and manipulate it as you need, you can find some useful examples of SPLIT functions in this thread:
Split function equivalent in T-SQL?
Assuming I'm correct and the date part is always on the right side of the string, you can simply use RIGHT and CAST to get the date (assuming, again, that the date is represented as yyyy-mm-dd):
SELECT CAST(RIGHT(YourColumn, 10) As Date)
FROM YourTable
However, Panagiotis is correct in his comment - You shouldn't store data like that. Each column in the database should hold only a single point of data, be it string, number or date.
Update following your comment and the updated question:
SELECT LEFT(YourColumn, LEN(YourColumn) - 10) + REPLACE(RIGHT(YourColumn, 10), '-', '')
FROM YourTable
will return the desired results.
I want a function to convert a varchar to hexadecimal in sql server. Please help me.
P.S. I will use unhex() in Hive to try to get the original value back. This is because my data contains special characters and backslash and the HIVE external table does not recognise it
You can try to use CONVERT function:
SELECT CONVERT(VARBINARY(MAX), 'myText')
Output:
0x6D7954657874
you can use
select try_convert(varbinary,varcharcolumn)
You should use try_convert to avoid errors when the conversion fails.. Also, varbinary(n) is a better alternative to varbinary(max) as the latter would set the page size to 2GB, which might be excessive.
Hope this helps!
In my query (the database is a sql server) I use a RegEx for a select command like this:
SELECT * FROM test WHERE id LIKE '1[2,3]'
(This query is tested and returns the data I want)
I want to use a paramter for this RegEx. For that I definded the Paramter in iReport $P{id} as a string and the value is "1[2,3]".
In my query I use now this parameter like this:
SELECT * FROM test WHERE id LIKE $P{id}
As result I get a blank page. I think the problem is that the value of the parameter is defined with " ". But with ' ' I get a compiler error that the paramter isn't a string.
I hope someone can help me.
LIKE applies to text values, not to numeric values. Since id is numeric use something like this:
SELECT * FROM test WHERE id IN (12, 13)
with the parameter
SELECT * FROM test WHERE id IN ($P!{id_list})
and supply a comma separated list of ids for the parameter. The bang (!) makes sure that the parameter will be inserted as-is, without string delimiters.
Btw: LIKE (Transact-SQL) uses wildcards, not regex.
You can still use LIKE since there exists an implicit conversion from numeric types to text in T-SQL, but this will result in a (table or index) scan, where as the IN clause can take advantage of indexes.
The accepted answer works but it is using String replacement, read more about sql-injection, to understand why this is not good practice.
The correct way to execute this IN query in jasper report (using prepared statement) is:
SELECT * FROM test WHERE $X{IN, id, id_list}
For more information as the use of NOTIN, BETWEEN ecc. see JasperReports sample reference for query