Well, you still won't find the first occurrence with INDEX() since it hasn't got a comma in front.
Using the right tool (in this case LOCATE) for the job always helps!

On 01/11/2011 15:05, Charles Stevenson wrote:
What Wol & George Smith said.

MATCH's raison d'etre is _PATTERN_ matching.

That means:

(a) MATCH is relatively expensive to use for comparing simple literals.

(b) For MATCH, you need to enclose the pattern's literals in embedded quotes to ensure that it is not interpreted as a pattern. Per Wol's "M6AWT" example: M6AWT needs to be "'MCAWT'" or MATCH will reinterpret it as "'M'6A'WT'", a 3-piece pattern. Remember, every time MATCH is going to examine the 2nd argument to figure out what pattern you're talking about this time, which brings us back to point (a).

(c) MATCH will be confusing to the next maint pgmr: he'll think you're talking about PATTERN matching, not simple literals.

George's INDEX() gets it right for shear efficiency,

On 10/31/2011 2:17 PM, George Smith wrote:
If you are trying to look for an arbitrary delimited string, I think the safest thing to do is something like IF INDEX(',':X.STRING:',', ',':X.CODE:',',1)=0 THEN X.STRING=X.STRING:',':X.CODE
Efficiency matters if you do many iterations.
The LOCATE suggestions are arguably more readable if the rookie pgmr following you is not familiar with the INDEX() technique (yet).

You may be surprised if you compare INDEX() performance to functionally equivalent constructs using LOCATE, COUNT, MATCH, FINDSTR, etc..

If you're building X.STRING as you go, you might want to do something like:

   X.STRING = ','
       ... get X.CODE ...
   X.STRING = [ 2, LEN( X.STRING)-2 ]  ; * drop leading & trailing comma

Caveat: All the answers on this thread assume strings of a "reasonable" size. Today maybe a few, several KB?? Tomorrow???


On 10/31/2011 6:20 PM, Wols Lists wrote:
I notice nobody seems to have pointed out a MAJOR gotcha in using MATCH. If your code is as described, you'll avoid it, but what validation have you got in place on X.CODE? Is it possible that numbers could accidentally get into it? We did something like this years ago with a line something like IF TEXT MATCH USER THEN where USER was the department code followed by the user's initials. And while most departments were alphas, there were a couple of alphanumerics. All went well until Albert from M6 ran the code ... USER = "M6AWT" Who can see the landmine just waiting to explode ... ? Cheers, Wol

U2-Users mailing list
U2-Users mailing list

Reply via email to