>>>>Hi Terry. You missed something - even if you have an ON ERROR routine in effect it will not trap the error when you issue a SQL SELECT statement on a file that is not open.
>>>
>>>Is not this a programming logic error?
>>>
>>>Advice: Open the file:)
>>
>>Yes it is a programming error. But not trappable because VFP takes over ands tries to ask the end user what file to open instead of throwing the error. Thats the whole point dude!
>
>That the problem with SQL SELECT style DBF apps. Bloated temp directorys and bloated CDX's. Switch to SEEK. The planning is tighter, the CDXs are smaller and the app will scream like a C++ interface. Why CHUG along like a an overblown list server when there are features available that allow us to build apps that run like a swiss movement?
>
>One could wager that a lot of the negative press VFP gets is from "browser" implementations of what should be a transaction engine. Use of SELECT should be limited. When over used: Selects are just another too-easy method to build a browser app. - a grid - an expensive glorified spreadsheet - something for future prospects to couch their doubts with.

Terry, I dont disagree with anything you write here. I extensively use the VFP table functions and prefer them over SQL simply because my apps are more this way inclined. But that doesnt address the issue raised by this thread - which, by the way, does not affect me but I was simply trying to enlighten you as to the nuances of the discussion ;)