asked on

LIKE operator not matching exact strings?

Has anybody ever heard of the LIKE operator not matching exact strings? For example I would expect "WHERE lastname LIKE 'Smith%'" to return records like "Smith" and "Smithe". But I'm running into an issue where only "Smithe" is returned, not "Smith". The lastname column is an nvarchar.

One workaround I'm using is "WHERE lastname + ' ' LIKE 'Smith%'". It works, but this is causing a huge performance hit (around 20 times slower). I've tried PATINDEX, instead of LIKE, but it's not very fast either.

I'm looking for any suggestions, articles about this problem, or any confirmation of this problem.

Thanks

AaronAbend

look for a space after the "Smith "
in your data

select fname+'X'
and if it comes back Smith X instead of SmithX

you know that's the problem

or use righttrim to remove spaces
where righttrim(lastname) like 'Smith%'

knightEknight

all of the below work for me:

select 'Smith'
where 'Smith' like 'Smith%'

select 'Smith '
where 'Smith ' like 'Smith%'

select 'Smithe'
where 'Smithe' like 'Smith%'

select 'Smithe '
where 'Smithe ' like 'Smith%'

is there something else in your query that may be excluding the Smith row(s)?

AaronAbend

Sorry.. my example for diagnosis should be

select lastname+'X'

and the trim statement should be

where rtrim(lastname) like 'Smith%'

Guy Hengel [angelIII / a3]

>Has anybody ever heard of the LIKE operator not matching exact strings?
I did not. Looks curious?!

Lowfatspread

what are you actually doing?

"WHERE lastname LIKE 'Smith%'"

seems to have the wrong number of quotes for dynamic sql....

lastname like 'SMITH%' will return SMITH AND SMITHE

"WHERE lastname LIKE 'Smith%'"

should be

'WHERE lastname like ''SMITH%'''

that's all single quotes 6 in total

awking00

Perhaps it could be the problem is that the spaces are in front. If so, use lefttrim -
select ...
where lefttrim(lastname) like 'Smith%';

eric0213

ASKER

I looked at the records and there are no spaces on either side. I added an RTrim and it didn't help.

This seems like such a basic thing, I'm not sure why the records don't get returned. I was hoping someone had seen this before, either in an old version of MSSQL, or when using indexed columns, or when there was a full moon.

I've spent a good chunk of morning searching for someone else with this issue, but nothing. I've searched here, the newsgroups, MSDN, and the web (not exhaustively of course).

knightEknight

what does this do on your system?

select 'Smith'
where 'Smith' like 'Smith%'

select 'Smith '
where 'Smith ' like 'Smith%'

select 'Smithe'
where 'Smithe' like 'Smith%'

select 'Smithe '
where 'Smithe ' like 'Smith%'

eric0213

ASKER

knightEknight, they all return one record.

awking00, tried, no luck.

Lowfatspread, the double quotes were just there to delimit what I had in my SQL, they weren't really in the statement.

Essentially, I want my LIKE statement to function like below (LIKE is not case-sensitive). The UPPER function below is costing me as much as appending a space.
WHERE lastname LIKE 'Smith%' OR UPPER(lastname) = 'SMITH'

knightEknight

If each of the above statements returned one record, then the LIKE operator is working normally on your system. Is there something else in your query that may be filtering out the expected rows? Can you post your entire query?

ASKER CERTIFIED SOLUTION

AaronAbend

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

AaronAbend

In 20 years of SQL writing I have seen many occasions where things just like this occurred... and in every case the problem was either the data or SQL logic on my side.

So do not look for an error in SQL in handling this simple SQL unless you are running a beta version or something (by the way, in your reply post your version just in case .. select @@version and send us the results)

Guy Hengel [angelIII / a3]

my suggestion:
points to AaronAbend, as to his remark of using the ascii function to identify what characters are really in the string to identify the "culprit" data.
angelIII, page editor