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. Instead VFP pops up a dialog box asking the user to open "a" file, but the dialog does not tell the user what file its looking for. Its a non-trappable condition.

When the wrong file or no file is selected then control returns to your app which, more than likely, will generate a trappable error and kick in your error handler. By which time the user is either blaming you for this weird "open a file" dialog or, worse, selected a file which actually ran the SQL command and did something horrible :)




>>Tell us again how you handle these occurrences in your code such that your does not exhibit this bug (as you call it).
>>
>
>on error do errhandler?
>
>Are you saying that VFP should not report errors - or are you saying that VFP should not report errors when it suits a particular vanity related misnamed, mislocated files (those are errors/bugs too, No?)
>
>It seems what your saying is "I deleivered a program to a user but forgot something and now the damned program is broadcasting to the user that I forgot to include something in the delivery"
>
>Lets say you implement the "SET OPENDIALOG OFF". Then what happens? The file is not available - so any downstream error that rears its head because of the missing file is a legimate error?
>
>Do you want VFP to hide your mistakes from your user and yourself? Are you searching for a "plausible deniability".
>
>Jim - this sure seems like denial to me. It also seems that VFP is being asked to participate in a conspiracy to pretend an error did not occur.
>
>An application bug is a bug - fix it - we need to make sure we don't give our prospects (and their hillbilly IT teams) any fodder for negative attitudes regarding our development platform. We've been going through that for years.
>
>Fix your bugs - do ask VFP to help you hide them!:)