Wednesday, February 22, 2006
A sensitive SQL issue
Unlike unix world, Microsoft world is not much finicky about alphabet’s case. It really doesn’t matter about in which we execute commands. Mostly, it accepts all phase of alphabets (lower, UPPER and mIxEd). As like other MS products, SQL Server do accepts commands in all cases. However few SQL commands are case sensitive. For example BCP command. This command-line program’s parameters are case sensitive.
In contrary to windows user name and password, SQL Login name and password are generally not case sensitive, but it depends on the SQL Server’s collation setting. If the SQL collation is case sensitive, then SQL login passwords also case-sensitive. In a case sensitive SQL Server or Database, all comparison operators, SQL identifiers are sensitive about case.
… WHERE name = ‘SQL’ is different than … WHERE name=’sql’
… WHERE NAME = ‘SQL’ is different than … WHERE name = ‘SQL’
So, if the business is not much concern about the alphabet case, then we need to chose a collation which named like CI (case Insensitive) rather than CS (case sensitive).
In contrary to windows user name and password, SQL Login name and password are generally not case sensitive, but it depends on the SQL Server’s collation setting. If the SQL collation is case sensitive, then SQL login passwords also case-sensitive. In a case sensitive SQL Server or Database, all comparison operators, SQL identifiers are sensitive about case.
… WHERE name = ‘SQL’ is different than … WHERE name=’sql’
… WHERE NAME = ‘SQL’ is different than … WHERE name = ‘SQL’
So, if the business is not much concern about the alphabet case, then we need to chose a collation which named like CI (case Insensitive) rather than CS (case sensitive).
Comment on GO
/* */ is the one among the two commenting commands available in T-SQL Server which is used to comment a paragraph (block comment). The other – (double dash) is used to comment a line (commonly known as in-line comment).
Including GO command inside the block comment ( /* ….. */ ) invalidates the comment and generates an error. We can’t embed GO command within the block comments. If we want to do so, then we need to put an inline (--) command before the GO signal.
/*
select @@version
go
*/
The above block comment throws errors as:
Server: Msg 113, Level 15, State 1, Line 1
Missing end comment mark '*/'.
Server: Msg 170, Level 15, State 1, Line 1
Line 1: Incorrect syntax near '*'.
However, adding an inline comment before the GO signal makes SQL Server parser to treat the comments as comments.
/*
select @@version
--go
*/
Including GO command inside the block comment ( /* ….. */ ) invalidates the comment and generates an error. We can’t embed GO command within the block comments. If we want to do so, then we need to put an inline (--) command before the GO signal.
/*
select @@version
go
*/
The above block comment throws errors as:
Server: Msg 113, Level 15, State 1, Line 1
Missing end comment mark '*/'.
Server: Msg 170, Level 15, State 1, Line 1
Line 1: Incorrect syntax near '*'.
However, adding an inline comment before the GO signal makes SQL Server parser to treat the comments as comments.
/*
select @@version
--go
*/
Tuesday, February 07, 2006
SQL used for evil
It is something different than SQL Injection attack...
"SQL used for evil" blog entry shows how a malicious use of T-SQL which will cheat DBAs and make them to think something really went wrong at the SQL Server.
Fellow DBAs... beware of this kind of DoS attacks.
"SQL used for evil" blog entry shows how a malicious use of T-SQL which will cheat DBAs and make them to think something really went wrong at the SQL Server.
Fellow DBAs... beware of this kind of DoS attacks.
