>David, George-
>
>>Arguments like this to prove one language supreme over another are pretty much a waste of time, effort and CPU cycles IMHO.
>
>I agree that VFP is _not_ the tool for this task, but I've been interested in trying to figure out how to do it in VFP to help me better understand both VB and VFP. Sadly, I'm quite stuck. I couldn't care less about the better/faster aspect.

Nancy, I think Ed Rauh's CLSHEAP might have something in it to help, but I think that it's a waste of time.

>As for the weighting. Yeah, it's weighted towards VB/VC, but, again, I'll just mention that the VB guys are _not_ the ones who started this. And, the matrix problem was designed by someone for whom this sort of I/O task is common, and he didn't have any idea of what VFP supports or not.

This is true, but they designed the test and may have misunderstood what was meant by file I/O. Unquestionably, VB can do some things in this area that there's no direct way for VFP to emulate without incurring significant additional overhead that isn't present in VB. Does this mean that, in terms of file I/O, VB will always be better. No! Simply put, the statement, for my money, is too general to have any significant meaning. I've never compared VB's straight reading of a file to VFP's. Would STRTOFILE() vs. a VB byte-by-byte file read be as indicative. I think VFP would look better < g >, but I don't think that the results would be comparing apples to apples.

>Not that they aren't a little gleeful about the results. And annoyingly so, too. I still can't really blame them.