Visual Basic comparing two .txt documents

[Fairlight]

When asked his whereabouts on Thu, Dec 06, 2007 at 10:26:47PM -0500, Mike
Fedkiw took the fifth, drank it, and then slurred:
> I am asking this here because it seems like a lot of you do more then
> filepro.
>
> I have an inventory file (invy.txt) with about 22,000 records in it. each
> line in the (invy.txt) file contains data like the following. (VEND UPC#
> MFG# DESCRIPTION ETC...). I have another file that is just a list of
> image names with about 12000 items in it "images.txt". looks like this
> (VEN_UPC.JPG) example= "pen_55555.jpg".
>
>  The programmer I hired to do this is attempting to build arrays for each

You realise that you never actually define "this" at all before the point
at which you use it, nor do you clearly and fully define it afterwards,
right?

>  letter in the alphabet on the (vend_upc) and load in the appropriate
>  records from my invy.txt file. He is then looking into the array that
>  matches the first letter of the image we are looking for from my
>  (images.txt) file.

Note that the project is ill-defined.  You never actually say exactly what
you want to do with a complete specification.

If I had to -guess-, I'd say you're trying to find the appropriate image
for each item in the inventory file.

But...  You don't say what needs to be spit out or otherwise done when you
find a match, you don't detail what should happen if there is no match.
This incomplete description is less than usable.  Heck, based on lack of
description, you could be trying to eliminate inventory records that have
no matching image.  Not enough data to go on .

I'm not even sure why people jumped into solutions without asking for
full clarification of the objectives.  First rule is to get a full
specification before tossing "solutions" at things.

> It is not very fast. I know nothing about visual basic programming but
> there has to be a faster way.  I have seen something about text searches
> that say they index the text file somehow.

Never send a VB programmer to do a perl programmer's job.  And yes, his
existing algorithm sounds dead slow and overly complex for even that part
of the project.

Still, more details are needed on specifically what you want to happen.
Banging out the record matching code is trivial enough in perl.  I thought
about just posting code until I realised you didn't clearly define what
should happen when, and that the code would be woefully incomplete because
the spec that hit the list was far too ambiguous to be usable.

If you have a complete breakdown of exactly what's supposed to happen, it
would be wise to repost with that information and see what comes forth.

mark->