In (non-English) book on T-SQL (SQL Server 2005) I read about:
SELECT * FROM ::fn_helpcollations()
Though, execution of it without "::"
SELECT * FROM fn_helpcollations()
In my SQL Server 2008 R2 gives exactly the same result.
What does "::" mean in T-SQL?
From MSDN:
However, when you call SQL Server
built-in functions that return a
table, you must add the prefix :: to
the name of the function:
SELECT * FROM ::fn_helpcollations()
Looks like you can omit the :: in SQL Server 2005 and 2008. The :: syntax will be supported for backward compatibility.
Related
Can someone help me to translate the below Oracle query to SQL SERVER syntax ?
with cte as(
select to_date('05-05-2022','mm-dd-yyyy') as eff_dt,
to_date('12-31-2022', 'mm-dd-yyyy') as exp_dt from dual
)
select eff,exp,round(months_between(exp,eff)) from(
select case when level = 1 then eff_dt
else add_months(trunc(eff_dt,'Y'),12*(level-1)) end as eff,
last_day(add_months(trunc(eff_dt,'Y'),12*level-1)) as exp
from
cte connect by level<=extract(year from exp_dt)-extract(year from eff_dt)+1)
;
Learn standard SQL language. MS SQL Server use standard SQL while Oracle has always wanted to go on its own dialect, despite the fact that Jim Melton, the technical mentor of Oracle was the reporter of the standard ISO SQL !
Well in any good book, you will find that CAST is the normative function to CAST... and CTE (Common Table Expression) is the normative construction to write recursive queries.
On this topic, you can use the paper I wrote many years ago : "Recursive Queries in SQL:1999 and SQL Server 2005"
Any idea why the two hashing functions in SQL Server and Oracle yield different results when hashing the non-breaking space character?
Oracle select standard_hash('a ', 'MD5') from dual; results in 25EF28EB5A5BE667C6222418E9E27E8E and doesn't match SQL select HASHBYTES ('MD5','a '); results in CE8F03020C81133B3A082F8051EB9FF6. Note the space after the input 'a' is a non-breaking space character.
Is there any good source that can lay out the differences?
This appears to be a character set or "collation" issue, where Oracle is in UTF-8 and SQL Server is in Latin 1252. My solution was to CONVERT the value to Windows Latin-1252 in Oracle before calculating the hash: select STANDARD_HASH(CONVERT('a ','WE8MSWIN1252'), 'MD5') from dual.
To find my collation/character set I did SELECT collation_name FROM sys.databases WHERE name = 'MY_DB_NAME'; in SQL Server and select * from nls_database_parameters where parameter='NLS_CHARACTERSET'; in Oracle.
First of all you need to establish which one is actually yielding "different" results:
Using your favourite search engine to find online hash generators and testing results.
External Resources
https://passwordsgenerator.net/md5-hash-generator/ - 99020CB24BD13238D907C65CC2B57C03
https://www.md5hashgenerator.com/ - 99020cb24bd13238d907c65cc2b57c03
https://www.miraclesalad.com/webtools/md5.php - 99020cb24bd13238d907c65cc2b57c03
SQL Server
select HASHBYTES ('MD5', 'a ')
SQL Server 2014 SP3 (12.0.6024.0) - 0x99020CB24BD13238D907C65CC2B57C03
SQL Server 2019 (15.0.2080.9) - 0x99020CB24BD13238D907C65CC2B57C03
Oracle (using https://dbfiddle.uk/)
select standard_hash('a ', 'MD5') from dual;
Oracle 21c - 0x99020CB24BD13238D907C65CC2B57C03
Oracle 18c - 0x99020CB24BD13238D907C65CC2B57C03
Oracle 11gR2 - "ORA-00904: "STANDARD_HASH": invalid identifier"
Conclusion
You can see that your Oracle produced answer differs even from other Oracle answers. What version of Oracle are you running? What other options are set, such as collation etc.?
I'm writing a little script to extract the password hashes of SQL Logins on 2008 and 2012 instances. Part of my code looks like this...
SELECT CONVERT (VARCHAR(514), (SELECT CAST (LOGINPROPERTY('sa', 'PasswordHash') AS varbinary(256))), 2)
When I run this in a 2012 instance, it all works fine. But when run on a 2008 instance I get a blank result. I've checked that the SQL login is valid and has a password on the 2008. The online documentation tells me that all the functions are valid between both versions.
What is the difference between the versions?
Regards,
JC
Hash algorythms used:
SQL Server 2012 and above use SHA2-512 (512 bytes hash)
SQL Server 2000 to 2008 R2 use SHA1 (160 bytes hash)
You can also uses this query and DMV:
Select password_hash, * From sys.sql_logins Where name in ('sa')
It gives the same hash that this query:
Select CONVERT (varchar(512), (LOGINPROPERTY('sa', 'PasswordHash') ), 2)
Use this one if you want a varchar starting with 0x
Select CONVERT (varchar(514), (LOGINPROPERTY('sa', 'PasswordHash') ), 1)
I'm working on an application which queries live data on SQL Server. The user enters a name within '% %' marks to search. Ie. if the user was to search for the owner of a property such as Noble, they would enter %noble%.
We recently upgraded both the application and the SQL Server that stores the data from SQL Server 2005 to SQL Server 2012.
The existing query and the new query are identical:
SELECT aurtvalm.pcl_num
FROM aurtvalm
INNER JOIN rtpostal ON aurtvalm.ass_num = rtpostal.ass_num
WHERE rtpostal.fmt_nm2 LIKE ?
In the old version, the above query produces 16 results. The exact same query in 2012 version produces an error:
Incorrect Syntax near '?'
Has the use of the ? symbol changed since SQL Server 2005?
That because you have incorrect syntax. You have to use parameter instead of question mark. Something like:
SELECT aurtvalm.pcl_num
FROM aurtvalm
INNER JOIN rtpostal ON aurtvalm.ass_num = rtpostal.ass_num
WHERE rtpostal.fmt_nm2 like #param
In Oracle, in order to do a linguistic sort, suppose with arabic characters, I use following :
ALTER SESSION SET nls_sort='arabic'
How can I achieve linguistic sorting in SQL Server 2008 ?
SQL Server has the concept of collations which affect ordering and comparison operations.
If your data is configured using a different collation to the one you require, you can force a specific one to sort by in your ORDER BY statement like this:
SELECT *
FROM Table
ORDER BY TextColumn COLLATE Arabic_CI_AS