Application.Match vs very large data arrays - A.M looses

[Rhudi]

I have a piece of code to find an index into a text array, looking for a line that contains a string match.

I've learned that Application.Match is fairly useful as long as I know how it behaves. The returned number is always (+1) in the text array, so I have to adjust when that matters. Also, A.M will default to an exact match, but will use wildcards.

What threw me for a serious loop, is that Application.Match does not play well with very large arrays. I believe it is a memory limitation (but I forget).

Here is the code I use:

Please Login or Register  to view this content.

Today, running this would give me an application mismatch, when I know it works (DIMs are variant where needed, etc.)

So, here is how I got past that:

Please Login or Register  to view this content.

My question is... Should I just use my ugly for-next loop in place of Application.Match, or should I use Application.Match and trap errors (or test the UBound valuse is >= to some specific number)?

Being lazy, I'm inclined to just use what works.

I just noticed that I have to use the InStr() function for partial matches.

[Rhudi]

I've concluded that my solution works. Actually, I can use that to continue looping if I believe that I will find multiple matches.

In fact, I also use Filter() to make smaller arrays, when I know there will be multiple hits of the data for which I'm searching.

As an example, within a Cisco router dump, using filter to match "neighbor a.b.c.d" will build me a smaller array with all the matching neighbor statements. From that, i can loop-count through the smaller array, then use the lager array-count-through to find specific sections within the source data.

More often than not, asking you guys in-forum how to do this stuff slows me down enoug to actually think about what I need to accomplish. Thanks forum!