When comparing two strings how to avoid checking if a string is of different case in MS SQL 2000
Example:
String1 = Anish
String2 = anish
When comparing Anish = anish the result will be "the strings are not equal". How we compare these strings in that way?
Here is some information about case sensitivity. The thing that i can see is that the problem is how the server is installed.
Case sensitive search
Change the collation of the strings to some form of CI (case insensitive).
E.g. COLLATE Latin1_General_CI_AS
Try the following queries seperately in Northwind database:
SELECT * FROM dbo.Customers WHERE Country COLLATE SQL_Latin1_General_CP1_CS_AS ='Germany'
SELECT * FROM dbo.Customers WHERE Country COLLATE SQL_Latin1_General_CP1_CS_AS ='geRmany'
String Comparison in java is used to compare two different strings.
We can compare string irrespective of case(upper case/ lower case).
Consider str1="HELLO WORLD";
str2="hello world";
If we want to compare these to strings, there are two ways:
String compareTo (String).
String compareToIgnoreCase(String).
Comparing String:
str1 compareTo (str2);
This statement will produce false as the output because java is case sensitive language.
You can also compare the string irrespective of their case using the statement:
str1 compareToIgnoreCase (str2);
This will produce the output true because it will check only the character that stored in str1 and str2 without worrying about the case.
Related
I am using SQL Developer over a backend Oracle DB. I have a record where the buyer name is Pete Hansen.
Why I try
select * from data1 where buyer = 'Pete Hansen';
I get the result, no problem. However, when I use the following, I do not get any results:
select * from data1 where buyer like 'Pete Hansen';
Also, when I try the following, I do not get any results
select * from data1 where buyer like 'Pete Hans_n';
but the following works well:
select * from data1 where buyer like 'Pete Hans_n%';
Could you please help me understand? Thanks in advance.
Your buyer column seems to be defined as char; you can see the issue reproduced in this db<>fiddle, but not when the column is varchar2.
The documentation for character comparison explains the difference between blank-padded or nonpadded comparison semantics. When you compare them with =, because both the column and the string literal are `char, blank-padded semantics are used:
With blank-padded semantics, if the two values have different lengths, then Oracle first adds blanks to the end of the shorter one so their lengths are equal. ... If two values have no differing characters, then they are considered equal. This rule means that two values are equal if they differ only in the number of trailing blanks. Oracle uses blank-padded comparison semantics only when both values in the comparison are either expressions of data type CHAR, NCHAR, text literals, or values returned by the USER function.
When the column is `varchar2 then nonpadded semantics are used:
With nonpadded semantics, ... If two values of equal length have no differing characters, then the values are considered equal. Oracle uses nonpadded comparison semantics whenever one or both values in the comparison have the data type VARCHAR2 or NVARCHAR2.
LIKE works differently. Only your final pattern with % matches, because that is allowing for the trailing spaces in the char value, while the other two patterns do not. With the varchar2 version there aren't any trailing spaces to the other two patterns also match.
It's unusual to need or want to user char columns; varchar2 is more usual. Tom Kyte opined on this many years ago.
I suspect it may have to do with trailing white spaces, which like operator is not forgiving about but = is. To test that, try
select * from data1 where trim(buyer) like 'Pete Hansen';
In my MariaDB environment I want to check to see if there are any values in the table "contacts" and the column "firstname", where the first letter in the string value is lower case. My question is: will this do the trick?
SELECT * FROM contacts
WHERE (firstname) LIKE '%[abcdefghijklmnopqrstuvwxyz]%';
MySQL does not support syntax [...] with LIKE.
You can also use the following condition to check if the first character of firstname is lowercased:
BINARY lower(left(firstname, 1)) = left(firstname, 1)
Another option is to use a regex (shorter to write and easier to understand):
BINARY firstname RLIKE '^[a-z]'
Please note that both expressions will not use an existing index on firstname, since functions or regexes comes into play.
In order for this to work in general, I believe you have to cast to binary:
cast(firstname as binary) rlike '^[a-z]'
Or:
cast(left(firstname, 1) as binary between 'a' and 'z'
I'm looking for a query that would allow the user to use a variation of characters while searching for a result. The character positions are completely random. We use special characters È,Š,Ć,Č,Ž and Đ so all of the variations have to match, because most of users do not know how to spell correctly.
Example:
MISIC
MISIĆ
MISIČ
MIŠIC
MIŠIĆ
MIŠIČ
You can search it by using COLLATE
SELECT *
FROM TableNAme
WHERE
columnName COLLATE Like '%MISIC%' COLLATE Latin1_general_CI_AI
latin1 makes the server treat strings using charset latin 1,
basically ascii.
CI specifies case-insensitive, so "ABC" equals to "abc".
AI specifies accent-insensitive,so 'ü' equals to 'u'.
for more information collation go through the
Collete
refereance : #JINO SHAJI
as per #Adephx comment this is working as expected with few modification
SELECT * FROM [TABLE] WHERE [COLUMN] LIKE '%NAME%' COLLATE Latin1_general_CI_AI
Applying COLLATION is a great practice, especially if we want to get rid of all Accent-marks, however, if we need more granular control over individual accent-characters (È,Š,Ć,Č,Ž), we can do something like below to selectively compare individual accent-characters.
Most DBMSs provide string-comparison functionality based on how the words sound (pronounced). SQL Server provides two built-in functions for this: SOUNDEX() and DIFFERENCE(). In this scenario we can do this:
IF (DIFFERENCE('MISIC', 'MISIĆ')>=4)
AND (DIFFERENCE('MISIC', 'MISIČ')>=4)
AND (DIFFERENCE('MISIC', 'MIŠIC')>=4)
AND (DIFFERENCE('MISIC', 'MIŠIĆ')>=4)
AND (DIFFERENCE('MISIC', 'MIŠIČ')>=4)
PRINT 'Same word'
ELSE
PRINT 'Different word.'
Actually, in many languages 'Š' sounds quite different than 'S', therefore SQL Server considers them as less-compatible, but here is a workaround to impose equivalence:
WITH words AS (SELECT value FROM STRING_SPLIT(N'MISIĆ,MISIČ,MIŠIC,MIŠIĆ,MIŠIČ', ','))
SELECT
value,
CASE WHEN (DIFFERENCE('MISIC', replace(value,'Š','S'))>=4)
THEN 'Same word'
ELSE 'Not same'
END AS 'Comparison'
FROM words
Output:
value comparison
----- ----------
MISIĆ Same word
MISIČ Same word
MIŠIC Same word
MIŠIĆ Same word
MIŠIČ Same word
Above example will work in "Microsoft SQL Server 2016" or above, note that the STRING_SPLIT() function is only used to iterate over the array of words/strings, this function is not available in SQL Server 2014 or below.
Hope this helps.
I need a select query that shows me identical address fields but is case sensitive.
Example:
smith road 1 **DOES NOT** match to Smith Road 1
But,
SMITH ROAD 1 **DOES** match to SMITH ROAD 1.
If anyone knows the answer could you please explain as simple as possible, as I would like to understand and not just "copy and paste".
What you want:
SELECT * FROM T_AV_Adressen
WHERE ADR_Name = 'Sears AG' COLLATE Latin1_General_CS_AS
Case-insensitive:
WHERE ADR_Name = 'Sears Ag' COLLATE Latin1_General_CI_AS
You need collations to tell (Microsoft) SQL-Server how to compare two string values.
Sorting in Czech for example works different from sorting in English.
By specifying CS/CI, you can also tell SQL server whether he should differentiate between capital/non-capital letters (case-sensitivity). Since equality is also a comparison, a collation can also appy to an equality comparison, not just to sorting.
To find duplicate entries AND differentiate between capital and non-capital letters:
SELECT *
FROM T_AV_Adressen AS adr1
INNER JOIN T_AV_Adressen AS adr2
ON adr2.ADR_Name = adr1.ADR_Name COLLATE Latin1_General_CS_AS
AND adr2.ADR_UID <> adr1.ADR_UID
SQL-Server by default is case-insensitive, so you don't need to specify a CI collation. Also, SQL-Server ignores leading and trailing whitespaces, so field1 = field2 is actually the same as LTRIM(RTRIM(UPPER(field1))) = LTRIM(RTRIM(UPPER(field2)))
If you're using PostgreSQL, it will be case-sensitive by default.
So IF you're using PostGre, field1 = field2 would suffice, or LOWER(field1) = LOWER(field2) if you need case-insensitive.
Another solution for Postgre to compare case-insensitive is field1::citext = field2::citext
Note that lower is more secure than UPPER, as some characters don't have an uppercase equivalent, e.g. the German double-s (ß)
There's the (almost religious) discussion, if you should use LIKE or '=' to compare strings in SQL statements.
Are there reasons to use LIKE?
Are there reasons to use '='?
Performance? Readability?
LIKE and the equality operator have different purposes, they don't do the same thing:
= is much faster, whereas LIKE can interpret wildcards. Use = wherever you can and LIKE wherever you must.
SELECT * FROM user WHERE login LIKE 'Test%';
Sample matches:
TestUser1
TestUser2
TestU
Test
To see the performance difference, try this:
SELECT count(*)
FROM master..sysobjects as A
JOIN tempdb..sysobjects as B
on A.name = B.name
SELECT count(*)
FROM master..sysobjects as A
JOIN tempdb..sysobjects as B
on A.name LIKE B.name
Comparing strings with '=' is much faster.
In my small experience:
"=" for Exact Matches.
"LIKE" for Partial Matches.
There's a couple of other tricks that Postgres offers for string matching (if that happens to be your DB):
ILIKE, which is a case insensitive LIKE match:
select * from people where name ilike 'JOHN'
Matches:
John
john
JOHN
And if you want to get really mad you can use regular expressions:
select * from people where name ~ 'John.*'
Matches:
John
Johnathon
Johnny
Just as a heads up, the '=' operator will pad strings with spaces in Transact-SQL. So 'abc' = 'abc ' will return true; 'abc' LIKE 'abc ' will return false. In most cases '=' will be correct, but in a recent case of mine it was not.
So while '=' is faster, LIKE might more explicitly state your intentions.
http://support.microsoft.com/kb/316626
For pattern matching use LIKE. For exact match =.
LIKE is used for pattern matching and = is used for equality test (as defined by the COLLATION in use).
= can use indexes while LIKE queries usually require testing every single record in the result set to filter it out (unless you are using full text search) so = has better performance.
LIKE does matching like wildcards char [*, ?] at the shell
LIKE '%suffix' - give me everything that ends with suffix. You couldn't do that with =
Depends on the case actually.
There is another reason for using "like" even if the performance is slower: Character values are implicitly converted to integer when compared, so:
declare #transid varchar(15)
if #transid != 0
will give you a "The conversion of the varchar value '123456789012345' overflowed an int column" error.