I guess I have to agree with you Walter, for some of the reasons you outline, as well as some of mine.

It goes without saying that most every programmer will use what he/she is most comfortable with. and for that reason, VFP usually has built-in more ways than one, to skin the cat, so to speak. Everone who has had to follow another programmer by modifying or updating code, has had the hair pulling trying to figure out the legacy code. I know I have, and I have even had to do partial re-designs on legacy code that was stuck in old habits instead of being optimized for performance. I used to be guilty of that as well, so I cannot blame anyone for doing something I am also guilty of.

The outfit I work for, is less interested in my developing in such a way as to preserve my skills for the future than they are in the delivery of the current project running as optimum as possible. After all, we are providing a solution, and are competing vety hard to deliver a superior one. In the instant example, the SEEK()/INDEXSEEK() functions are way faster than Select SQL. This is one of the big advantages in using VFP as opposed to using VB as a front end. Anytime I can SEEK a record in a 1.5 to 2 million record table and return it within a second or so as opposed to the 2.5 to 3 minutes for a similar SELECT, I go for it, and thus am a small step ahead of my competition or at least keeping up with them.

When it comes time to migrate or upsize, that is the time to get busy with the SQL statements as that is the only way they will work. But until then, I recommend the developer deliver an optimized product designed on the criteria at the time of development. You will have more users happy with your product, which equals more development business in the future. Of course if you are only developing in-house, and do not have to face competition, mt logic would have to change, I guess?