I have a field that contains strings such as 'Blah-OVER', 'Blah-OveR', etc. and want to select them without the 'over's. This only catches the first case (so to speak) and not the others:
SELECT field as "before", REPLACE(field, 'OVER', '') as "after"
How do I just get them all to say 'Blah-' (preserving the case of what's left) without attempting to cover every case combination with another nested REPLACE function?
Use a case insensitive collation:
SELECT field as "before", REPLACE(field COLLATE SQL_Latin1_General_Cp1_CI_AI
, 'OVER', '') as "after"
See COLLATE for list of collation names so you choose the one appropiate for your data.
Update
Ok, so I missed your actual request (change case of input, not find case-insensitive). The proper solution is... not to change the input but use an adequate collation for your data. If the data must be displayed in a specific format, use display options in the client, eg. CSS text-transform:uppercase, not in the server SELECT.
There isn't any built-in SQL function to do this transformation in-place, but is trivial to build a CLR function that uses RegEx. (On SQL 2005, not on SQL 2000... doh, I need more coffe).
I'm not familiar with SQL Server, but maybe it allows you to make use of regular expressions. These usually offer a case-insensitive mode (set via the i-flag).
Otherwise you could uppercase before the replace call, e.g.
SELECT field as "before", REPLACE(UPPER(field), 'OVER', '') as "after"
Related
I have a situation when doing a simple select query with a specific arabic name like the following "رفعة" the query returns more then one results. It rightly returns "رفعة", but it also returns "رفعت".
SELECT * FROM Table where ArabicName = N'رفعة'
I have encountered two other situations as well. When querying with "حياة" it returns "حياة" and "حيات".
When querying with "نعمة" it returns "نعمة" and "نعمت".
I have searched online for answers, but without luck.
Has anyone encountered this situation before?
Your problem is related to collation and you should understand what that means especially last few letters in collation Arabic_100_CI_AS.
CI means case insensitive, also you have option to set CS which means case sensitive
AS means accent sensitive, same as case there is option AI which means accent insensitive
Well, this collation can be set on server, database, column level or you can explicitly search adding COLLATE command at the end of statement.
I was able to fix the issue by adding the following to the query: COLLATE Arabic_100_CI_AS
SELECT * FROM Table where ArabicName COLLATE Arabic_100_CI_AS = N'رفعة'
Nb! It did not work without specifying the _100_ in the collation specification.
I did search but could not see anything relating to my question:
SELECT
vSMS_R_System.Netbios_Name0 AS 'Name',
vSMS_R_System.Distinguished_Name0 AS 'LDAP',
vSMS_R_System.Operating_System_Name_and0 AS 'OS Version',
vSMS_R_System.Last_Logon_Timestamp0 AS 'Last Logon Time',
vSMS_R_System.Active0 AS 'Active State'
FROM
vSMS_R_System
WHERE
Distinguished_Name0 LIKE '%Site Servers%'
AND Operating_System_Name_and0 LIKE 'Microsoft Windows NT Server 6.%'
AND Last_Logon_Timestamp0 LIKE '%2017-02%'
When executing this query, no results are displayed, however removing the last line will execute the results without issues. It seems to be the wildcard for Last_Logon_Timestamp0 that's an issue here.
I've amended the last line of the query to the below:
AND Last_Logon_Timestamp0 LIKE '%2017%'
This displays the results I need. So it seems to be the hyphen causing problems when declaring the wildcard value in my original query.
Does this information needed to be handled differently? The hyphen doesn't appear to be an illegal character, but it does appear to be preventing the information from being displayed.
Assuming that last_logon_timestamp0 is some sort of datetime, then you should be using date/time functions, NOT string functions. So:
SELECT s.Netbios_Name0 AS Name,
s.Distinguished_Name0 AS LDAP,
s.Operating_System_Name_and0 AS [OS Version],
s.Last_Logon_Timestamp0 AS [Last Logon Time],
s.Active0 AS [Active State]
FROM vSMS_R_System s
WHERE s.Distinguished_Name0 LIKE '%Site Servers%' AND
s.Operating_System_Name_and0 LIKE 'Microsoft Windows NT Server 6.%' AND
s.Last_Logon_Timestamp0 >= '2017-02-01' AND
s.Last_Logon_Timestamp0 < '2017-03-01' ;
Notes:
Your code converts the column to the local date/time representation, using whatever internationalization settings happen to be set.
A time comparison allows the database to use indexes on the column, if they are available.
Table aliases make the query easier to write and to read.
Don't use single quotes for column names, because they are easily confused for string constants. They should only be used for string and date constants.
Try to avoid column aliases with spaces and other non-standard variables, so you don't need to escape the names.
Dear Friends,
I've faced with a problem never thought of ever. My problem seems too simple but I can't find a solution to it.
I have a sql server database column that is of type NVarchar and is filled with standard persian characters. when I'm trying to run a very simple query on it which incorporates the LIKE operator, the resultset becomes empty although I know the query term is present in the table. Here is the very smiple example query which doesn't act corectly:
SELECT * FROM T_Contacts WHERE C_ContactName LIKE '%ف%'
ف is a persian character and the ContactName coulmn contains multiple entries which contain that character.
Please tell me how should I rewrite the expression or what change should I apply. Note that my database's collation is SQL_Latin1_General_CP1_CI_AS.
Thank you very much
Also, if those values are stored as NVARCHAR (which I hope they are!!), you should always use the N'..' prefix for any string literals to make sure you don't get any unwanted conversions back to non-Unicode VARCHAR.
So you should be searching:
SELECT * FROM T_Contacts
WHERE C_ContactName COLLATE Persian_100_CI_AS LIKE N'%ف%'
Shouldn't it be:
SELECT * FROM T_Contacts WHERE C_ContactName LIKE N'%ف%'
ie, with the N in front of the comparing string, so it treats it like an nvarchar?
I'm writing a fairly complex stored procedure to search an image library.
I was going to use a view and write dynamic sql to query the view, but I need to use a full text index, and my view needs outer joins (MS-SQL 2005 full-text index on a view with outer joins)
So, I'm back to a stored procedure.
I need to search on (all optional):
a general search query that uses the full text index (or no search terms)
one or more categories (or none)
a single tag (or none)
Is there a way to do a conditional FREETEXT in the 'WHERE' clause? The query may be empty, in which case I want to ignore this, or just return all FTI matches.
...AND FREETEXT(dbo.MediaLibraryCultures.*, '"* "') doesn't seem to work. Not sure how a case statement would work here.
Am I better off inserting the category/tag filter results into a temp table/table variable, then joining the FTI search results? That way I can only do the join if the search term is supplied.
Thoughts?
I know it's a year later and a newer version of SQL but FYI...
I am using SQL Server 2008 and have tried to short circuit using
AND ( #searchText = '' OR freetext(Name, #searchText))
and I receive the message "Null or empty full-text predicate" when setting #searchText = ''. I guess something in 2008 has changed that keeps short circuiting from working in this case.
You could add a check for the empty search string like
where ...
AND (FREETEXT(dbo.MediaLibraryCultures.*, #FreeTextSearchFor) OR #FreeTextSearchFor = '')
(I have a feeling that freetext searches can't have null passed into them, so I'm comparing to an empty string)
If the term to search for is empty, the whole clause will evaluate to true, so no restrictions will be applied (by this clause) to the rows returned, and of course since its a constant being compared to a variable - I would think the optimizer would come into play and not perform that comparison for each row.
Hmm, I thought there was no short-circuiting in sql server?
AND (#q = '' OR FREETEXT(dbo.MediaLibraryCultures.*, #q))
seems to work just fine!
Strangely, the full text scan is still part of the execution plan.
Doesn't work on SQL Server 2014. I tried the suggested short circuit in one of my stored procedures, but it keeps evaluating the FREETEXT expression. The only solution I have found is the following:
IF ISNULL(#Text, N'') = N'' SET #Text = N'""'
SELECT ...
WHERE ...
AND (#Text = '""' OR FREETEXT([Data], #Text)
I have a list of company names and the user has to enter his company name to get into the system. Let's say we have the company "Pré ABC", now I want the user to be able to type "Pre" or "Pré".
First I thought this was build-in functionality of the LIKE statement, but unfortunately it isn't. Any thoughts?
This has to do with collation. Each database has its own collation (and any column can override that collation, too). In your case, you're looking for a collation that's not accent-sensitive, and not case-sensitive. Try configuring the database to "SQL_Latin1_General_CP1_CI_AI". That decodes as "code page 1, case-insensitive, accent-insensitive", which should make your queries work as desired.
SELECT 1
WHERE N'Pré ABC' COLLATE LATIN1_GENERAL_CI_AI LIKE N'%Pre%'