Ron,

I'm the first to admit that VFP isn't always the fastest solution. A lot of string manipulation like this can be done a few to several orders of magnitude faster in a language like C/C++. There are a couple of examples over on my website that show how to create a DLL using C++ and call it from VFP.

I was just trying to say that there was probably alternate plain VFP code that would have been a lot faster.

I helped a guy rewrite some code that was building a text output file with strtofile(,,.t.) commands in a loop and they complained about how long it took. Well all the time was being wasted in the file system I/O activity that technique requires. I suggested he swtch to using a single SET TEXMERGE with \\ commands in the loop, it was 100 times faster.

>I didn't blame VFP for that. The point was that the file needed to be parsed to get it done. With regular expressions I just needed to look for a pattern (telephone number) and do the crunching from there. Even this solution was done from within VFP (!), we just took a little side-step to get faster results.
>In the end everybody was happy because we reduced the process to seconds and not minutes.
>
>I sometimes like to think outside of the (VFP)box to get results. Don't get me wrong, VFP is more than great for what I need to do.