Solved

PATINDEX

Posted on 2006-06-27
12
607 Views
Last Modified: 2009-07-29
here's my msgID value:  AAAA061206003028314^74842238^QQQQ

the format of the msgID string is this:
  AAAA - endpoint
  061206 - DDMMYY
  003028314^74842238^QQQQ - ordernumber

i'm using this to strip the UNKNOWN number of zeros from the front of the ordernumber:  
(i want this:  003028314^74842238^QQQQ  to be this:  3028314^74842238^QQQQ )

LEFT(SUBSTRING(msgID,1,10)+SUBSTRING(msgID,11+PATINDEX('%[1-9]%',SUBSTRING(msgID,11,LEN(msgID)-10))-1,LEN(msgID) - 11),
LEN(SUBSTRING(msgID,1,10)+SUBSTRING(msgID,11+PATINDEX('%[1-9]%',SUBSTRING(msgID,11,LEN(msgID)-10))-1,LEN(msgID) - 11)) -2)

stupid oversight of mine, i am sure, but why am i getting this:  
AAAA0612063028314^74842238^QQ
instead of this:
AAAA0612063028314^74842238^QQQQ


0
Comment
Question by:dbaSQL
  • 5
  • 4
  • 3
12 Comments
 
LVL 50

Expert Comment

by:Lowfatspread
ID: 16995529
because of the -2?

wouldn't this be "better"

convert(varchar(10),convert(int,substring(msgid,11, charindex('^',msgid,11) - 11)))
+substring(msgid,charindex('^',msgid,11),len(msgid)- charindex('^',msgid,11) + 1)
0
 
LVL 17

Author Comment

by:dbaSQL
ID: 16995619
but lowfat, this is my value:  AAAA061206003028314^74842238^QQQQ
your suggestion gives me this:  3028314^74842238^QQQQ      
when i need this:   AAAA0612063028314^74842238^QQQQ

in this particular example, i only need to pull those two 00's after AAAA061206 but before 3028314^74842238^QQQQ
see, there's an unknown number of zeros here.  2, 3, 4...it varies
0
 
LVL 50

Accepted Solution

by:
Lowfatspread earned 250 total points
ID: 16995668
substring(msgid,1,10)+
convert(varchar(10),convert(int,substring(msgid,11, charindex('^',msgid,11) - 11)))
+substring(msgid,charindex('^',msgid,11),len(msgid)- charindex('^',msgid,11) + 1)
0
NAS Cloud Backup Strategies

This article explains backup scenarios when using network storage. We review the so-called “3-2-1 strategy” and summarize the methods you can use to send NAS data to the cloud

 
LVL 17

Author Comment

by:dbaSQL
ID: 16995745
perfect.  (and way less typing than mine)
but lowfat, i still don't see why mine wasn't cutting it.  do you?
0
 
LVL 69

Expert Comment

by:Scott Pletcher
ID: 16995917
Or:

LEFT(msgid, 10) + SUBSTRING(msgid, 10 + PATINDEX('%[^0]%', SUBSTRING(msgid, 11, 50)), 50)
0
 
LVL 69

Expert Comment

by:Scott Pletcher
ID: 16995953
Actually, upon reflection, I think I most prefer this:

STUFF(msgid, 11, PATINDEX('%[^0]%', SUBSTRING(msgid, 11, 50)) - 1, '')
0
 
LVL 17

Author Comment

by:dbaSQL
ID: 16996746
why do you prefetr that, scott?  i'm using this in a reconciliation procedure -- performance and runtime is of the essence.  why is one better than the other?
0
 
LVL 69

Expert Comment

by:Scott Pletcher
ID: 16996951
I think it will perform better.  It's also (much) shorter, and thus easier to interpret and change, IMO.
0
 
LVL 50

Expert Comment

by:Lowfatspread
ID: 16998733
a thought occurs what do yo expect to happen if the first number is actually zero...?
0
 
LVL 17

Author Comment

by:dbaSQL
ID: 17000055

  003028314^74842238^QQQQ - ordernumber

Lowfat, if you mean the first number in the ordernumber is actually a zero, then I just think we're kinda outta luck on that one, for sure.  I actually made the very same statement to the parties that be, but I was dismissed.  There is no guarantee that a legitimate ordernumber won't begin with a zero -- but, at this point, I simply haven't accounted for that.  I think, if that actually does occur, we may be invalidating the ordernumber by stripping the legitimate zeros.  As far as my reconciliation goes, it shouldn't hinder me, as I am running this on both sides of the recon -- so, the string still matches.  But, for obvious reasons, we don't want to invalidate the ordernumbers --- so, I believe I just need to emphasize this just a bit more to a few people, and see what's what.

Is that what you meant?

and scott, it actually does perform better -- runtime, i mean.  a teensy bit faster.  why is that?
0
 
LVL 69

Expert Comment

by:Scott Pletcher
ID: 17001981
Lots fewer functions and no string concatenation; SQL is slow at string concat.
0
 
LVL 17

Author Comment

by:dbaSQL
ID: 17002038
yes, definitely a bit slower w/the concatenation.  ok, thank you scott
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
T-SQL 10 35
Download ms sql express. 2 26
TSQL XML Namespaces 7 22
HTML <font style="color:red"> 9 31
Ever needed a SQL 2008 Database replicated/mirrored/log shipped on another server but you can't take the downtime inflicted by initial snapshot or disconnect while T-logs are restored or mirror applied? You can use SQL Server Initialize from Backup…
Ever wondered why sometimes your SQL Server is slow or unresponsive with connections spiking up but by the time you go in, all is well? The following article will show you how to install and configure a SQL job that will send you email alerts includ…
Using examples as well as descriptions, and references to Books Online, show the documentation available for date manipulation functions and by using a select few of these functions, show how date based data can be manipulated with these functions.
Viewers will learn how to use the SELECT statement in SQL to return specific rows and columns, with various degrees of sorting and limits in place.

856 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question