I wrote a stored procedure which on several declared variables uses regular expression.
Example:
IF #value_criteria like '%[^0-9]%'
SET #having_clause = 'HAVING value_criteria <=' + #value_criteria
....to my latter disappointment it runs on SQL Server 2000 which does not seem to "know" reg. ex. (unless extra DLL is installed which I cannot do.)
Is there an alternative to this statement which would work for SQL Server 2000 ?
Thanks
Your expression:
IF #value_criteria like '%[^0-9]%'
SET #having_clause = 'HAVING value_criteria <=' + #value_criteria;
is standard like syntax (for SQL Server). This structure for the pattern is support in SQL Server 2000. It does not require regular expressions.
The SQL Server 2000 documentation for like explains the support for this type of pattern.
Related
I'm trying to filter results from a Query i have created in Microsoft Query to pull data from a database into my Excel sheet. Specifically I'm trying to filter out based on the nth character of a string.
I can easily filter out the based on the first char:
SOPOrderReturnLine.ItemCode Like 'A25%'
But I have no idea how I could filter to show only entries where the 10th char = "A". I'm sure I have to use a Substring function, but it's not familiar to me and I'm struggling to get it to work.
Try to edit your sql query and enter the following statement:
select * from SOPOrderReturnLine where substring(SOPOrderReturnLine.ItemCode,10,1) = 'A';
The statement should work for a MySql database as well as for an Sql Server in the background; (I've tested it with an MySql database).
Hope this helps.
In MSQuery (Jet under the covers, I think), the function is Mid.
SELECT * FROM tblLocation WHERE (Mid(LocationName,2,1)='e')
to find a lower case 'e' in the second location.
I assume when you say MS Query, you are running a query against a DBMS (SQL Server or some other via ODBC).
The use of substr, substring or mid should work, depending on which DBMS. That said, unless you're using MS Access, I think most DBMSs will support the underscore character as "any single character." It might even work in Access, but I don't know for sure. Therefore, I think in addition to the suggestions you've gotten, this will also work in most cases:
SOPOrderReturnLine.ItemCode Like '_________A%'
If you want to use substring, don't hold me to these, but I think:
Oracle / DB2 / SQLite - substr
Microsoft SQL Server / Sybase / MySQL - substring
MS Access - mid
PostgreSQL -substr or substring
I cannot figure out why this is wrong. The syntax for an IFF is defined here:
https://msdn.microsoft.com/en-us/library/hh213574.aspx
Why does it complain about the IN operator?
It looks like you're using a version of SQL Server that does not support this function (pre SQL Server 2012). An alternative is to use a case statement like so:
Select NEWID(), m.MALEPUNKTYPE,
case when m.MALEPUNKTYPE in ('E17', 'E18') then 'D02' else null end
from AMALD m
This is supported from SQL Server 2005 onwards however it should work on earlier versions too
The following statements return different SOUNDEX values in SQL Server 2012 while they produce the same value in SQL Server 2008:
PRINT SOUNDEX('BAKHSHI') --B200
PRINT SOUNDEX('Bakhshi') --B220
Has anyone else had this issue in SQL Server 2012 and knows how to get around it?
According to https://msdn.microsoft.com/en-us/library/bb510680.aspx:
SOUNDEX function implements the following rules: If upper-case H or
upper-case W separate two consonants that have the same number in the
SOUNDEX code, the consonant to the right is ignored If a set of
side-by-side consonants have same number in the SOUNDEX code, all of
them are excluded except the first. The additional rules may cause the
values computed by the SOUNDEX function to be different than the
values computed under earlier compatibility levels. After upgrading to
compatibility level 110, you may need to rebuild the indexes, heaps,
or CHECK constraints that use the SOUNDEX function. For more
information, see SOUNDEX (Transact-SQL)
So you might want to try following Microsoft's upgrade path advice. Also, SOUNDEX is collation sensitive - are your 2012 DB collations the same as your 2008 collations?
I am on project of migrating databases from SQL Server 2005 to 2008.
During test I found one inconsistency. In accordance to BOL http://msdn.microsoft.com/en-us/library/ms186862(v=SQL.100).aspx (2008) and http://msdn.microsoft.com/en-us/library/ms186862(v=SQL.90).aspx (2005) returns varchar. So far both are the same. However if we pass to REPLACE function column type char then difference comes out. Look at this code
declare #test table
(
testcharstring char(25)
)
insert into #test
select 'Hello'
union
select 'World'
union
select 'Hello world '
select
'"'+testcharstring+'"' as original
,'"'+replace(testcharstring,'a','A')+'"' as afterreplace
--,'"'+replace(rtrim(testcharstring),'a','A')+'"'
from #test
Result from SQL Server 2005
original afterreplace
--------------------------- ---------------------------
"Hello " "Hello"
"Hello world " "Hello world"
"World " "World"
Result from SQL Server 2008
original afterreplace
--------------------------- ---------------------------
"Hello " "Hello "
"Hello world " "Hello world "
"World " "World "
T-SQL in SQL Server 2005 removes even legitimate trailing space, not to say that it threats char(25) as varchar(25). T-SQL in SQL Server 2008 approaches type more carefully and returns results in accordance of type which it receives for transformation
I have number places in different T-SQL objects, mostly in triggers. Main idea just to make minimal changes to keep same behaviour in SQL Server 2008
Possible ways to do it
Override built-in REPLACE function Quick search suggests that it impossible however my teammate wants to research that option
Use Rtrim() functions together with REPLACE. This will require replacement in exact places in code in multiple routines (where char columns are used)
Creating own version Replace in CLR to see that CLR allows me to keep SQL Server 2005 behaviour and then again search and replace function in exact location
I would like to ask everybody if somebody came across of this issue, how did you worked out?
Also any suggestion is also welcome, may be I just do not know what settings on server instance or database level can change behaviour.
Thank you in advance!
You have different SET ANSI_PADDING options, which can also be controlled by SET ANSI_DEFAULTS
As it stands, REPLACE behaves the same in both editions. Both (2005, 2008) say:
Returns nvarchar if one of the input arguments is of the nvarchar data type; otherwise, REPLACE returns varchar.
Edit: there are 2 Connect bugs/features
My answer above is probably wrong
http://connect.microsoft.com/SQLServer/feedback/details/259840/trailing-spaces-are-lost-when-a-char-value-is-fed-to-replace
Check DB compatible level:
http://connect.microsoft.com/SQLServer/feedback/details/126092/t-sql-replace-function-seems-to-be-broken-for-char-x-variables
And as a fix, sorry, I'd use rtrim, however is it a fix? You can't override replace, and if you plan on a clr urgent, why not wrap the replace/rtrim in a SQL udf
according to MS this is a correct behavior and SQL2005 had it wrong.
in you code you are using Replace() not only as corection function (Find a pattern and replace with another pattern) but also as Trim() function (if nothing found at least trim the incoming value)
but this is wrong when you are working with Char(). the only reason to use Char() as data type is to preserve the values data length at all cost.(IMHO) as in you need to ensure that returning Value length is ALWAYS the same regardless of actual stored character count.
this is important when you need to build some kind of structure using string concatenation
as in fixed length file for output, and do not care to bother with data length checks or conversions.
otherwise you might as well use varchar() or nvarchar()
http://msdn.microsoft.com/en-us/library/ms143359(v=sql.100).aspx
In SQL Server 2005, trailing spaces specified in the first input parameter to the REPLACE function are trimmed when the parameter is of type char. For example, in the statement SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>', the value 'ABC ' is incorrectly evaluated as 'ABC'.
In SQL Server 2008, trailing spaces are always preserved. For applications that rely on the previous behavior of the function, use the RTRIM function when specifying the first input parameter for the function. For example, the following syntax will reproduce the SQL Server 2005 behavior SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.
I'm using an Xml field in my Sql Server database table. I'm trying to search a word using the XQuery contains method but it seems to search only in case sensitive mode. The lower method isn't implemented on Sql Server XQuery implementation also.
¿Is there a simple solution to this problem?
If you're using SQL Server 2005, I'm afraid you're out of luck.
If you're using SQL Server 2008, you can use the upper-case function like this :
DECLARE #x xml = N'abcDEF!#4';
SELECT #x.value('fn:upper-case(/text()[1])', 'nvarchar(10)');
Here's a link on MSDN for the upper-case syntax and a couple search examples :
http://msdn.microsoft.com/en-us/library/cc645590.aspx
First link from google points to MSDN page:
contains Function (XQuery)
In order to get case-insensitive
comparisons, the upper-case or
lower-case functions can be used.