"Yes, "depending on available resources" is the operative phrase here.
On my admittedly-older workstation (1GHz Athlon64, ~700MB RAM), Split()
made Excel "run off into the bushes and not come back" (bonus points
for anyone who recognizes the quote), with the added bonus that you
can't break in the middle of a Split() operation."


In cases of low memory resources it's better to manage large data in
blocks. Fact is, the data is pulled from the file in a string. This can
be done in one shot or in blocks. Same goes for writing back to file.
In any case, the key element in this OP's scenario is the content of
each line. IMO, this is better handled using an array and looking for
matches in each element. That obviates having to find the next
linebreak via additional InStr() processes.


==============================
"On my workstation (the above-mentioned Athlon64), this takes about 3
seconds to run, with your appropriate data being found every 36 lines.
(This will be affected by how often "HATCH" is in the actual data, how
often the rest of the data matches what you're looking for, and what
kinds of data manipulation you actually do.)"


Well.., that's got to be a really old machine! Most systems run 1gb or
more RAM for over a decade now and so I suspect any business using
computers today has the resources available. My point was how much of
the resources is being used by other processes. If PageFile comes into
play then the process will take forever. The OP states there's 6m lines
of text and so I'd recommend processing in blocks of 50k to 100k lines
at a time *IF* the match text is in the string *before* dumping it into
an array for processing. If it's not there then grab the next block and
so on. You definitely don't want to loop the array if the match text
isn't even in the string, right?<g

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion