Paul,

Just a quick point, NOFILTER is an OK workaround for SELECT..WHERE, as you
say you will always get a file. But SELECT * (no where), the NOFILTER has a negative effect since it copied the entire file, when it this case, the rushmore version works OK...

But I agree, VFP is a great language, but it's also OK for us to point out weaknesses so the VFP developers can take them into consideration.
I know criticism is hard for all of us developers, but I've learned that a good critic makes us better programmers :)


>I will put this problem in a different way:
>
>Let's say that SELECT doesn't need NOFILTER because it always creates a separate file. The performance is bad when SELECT is heavily used in a program. But all functions and commands work as expected. Do you like it more in this way?
>
>IMHO, VFP is not an easy language. There are many traps and a programmer must know many details in order to make everything work perfectly. But it's extremly powerful/fast and an excelent tool for RAD. And very good from OOP perspective.
>
>Don't forget that the computers we use(d) were not so powerful in the past, they didn't have so much hdd space and so much memory. Regardless, VFP was always fast and powerful. Now, some of the technical solutions implemented in VFP may not be the best ones today. But maybe they were the best solutions a few years ago. VFP is also great at backward compatibility. There are countless applications that make heavy use of SELECTs. I don't think we want to be forced to change all those SELECT statemanets.
>
>IMHO, anyone that writes VFP code and uses SELECT has to read at least once the Help for this command. The behavior is explained pretty well there. And adding the NOFILTER word to a SELECT statement is not such a big effort after all.
>
>Vlad