>You mentioned "lastname, address, zip"; I guess-timated about 100 bytes x 47,000, or about 5MB for the one table. The other table is even less. There didn't seem to be a lot of memory requirements. (A single "string" can be 16MB).
>

I guess I never looked at it that way... arrays might definately speed things up.

>On the other hand, I've "crunched" 100-200,000 records on a P266 and the times where measured in "minutes" ... I really don't know why your app is taking so long.

I don't have an index set for this 8000 record table but I am using GO TOP & SKIP to step through them sequentially.

>
>Are you saying that each time you read one of the "8,700" records, you are reading each and every one of the 47,000 BM records ? Can't you build a few indexes here and there ... maybe some SOUNDEX() ones, or something similar ?

For each read of 47,000.... the 8,700 are completely scanned. I am thinking about just grabbing those records of the 8700 that have a matching zip code and then checking against that... assuming the zip codes are entered correctly (and present) in all records.

Never knew about the soundex() and it is very intriguing. Don't know though how it will react when you are comparing say...

1451 North Telegraph Rd

to

1451 N. Telegraph Road

to

1451 Telegraph

My "remove letter" idea gets this to match pretty good... within 90% removal factor.



I'm going to check into the ARRAY commands although my only problem is the "variable" number of fields per table when this program is run... depending on the input file, the number can vary. I need to work off of some specific fields so if I can develop some routines that pick out certain elements, that might be the ticket. There are alot of factors in this stupid APP that is taking for ever to complete.