Sudden appearance of Run-time error '13': Type mismatch in previously working code

I don't know what conclusion(s) can be drawn without seeing the data ... and the rest of the code.

Regards, TMS

OK, thanks for the update. Thanks for the rep.

Did you Google: What is the maximum number of elements in an array that excel vba can process

See: http://msdn.microsoft.com/en-us/libr...sedLimitsExcel

And, as far as I can see, the number of elements is only limited by available memory.

Regards, TMS

How were you declaring t?

What do you get for x when you use something like this?

Please Login or Register  to view this content.

I got the same run time error, using Filter or Application.Match
For arrays, I always use "Dim x$()" - I just don't like seeing "Variant" in my variable list.
the variable 't' is declared as a Variant, as it will either be an integer that matches the line number in my array or an error.
When I use 't' in that way, the next statement to use that number will be "If Not IsError(t) then ..."
---
TMS's answer is spot on about RAM.
---
The array I'm reading is filled from a text file that contains a Cisco Router "show run" configuration dump.
However, in the recent problem that I had (caused by myself) I had copied the router data from an internal server that uses software call Rancid. That file was significantly larger as Rancid will prepend all the hardware inventory data that it can figure out from the router.
What I believe I should do if have some way to query the system to find out how much RAM is available and generate a warning if the array may be too large.
I suppose that alternatively, I could do an "On Error..." trap right before I try to manipulate that array and if I get RT Error 13, I know it should be because the array is too large.
---
If this is a limitation to the amount of free RAM, I've always said that I need more memory, I just forget why. :P