Hi Jos,

I agree with you. See my post to George.

>Hi George.
>
>With all due respect I dont think this thread topic is about coding practices per se. I think its about two specific points (1) the fact that under certain (error) conditions VFP chooses to present an open dialog to the user instead of throwing an error which, in turn, could be caught by the developer, and (2) the open dialog does not tell the user even what file it is looking for.
>
>You are saying that correct and defensive coding practice could be used to avoid this and sure this is true. However, the point being made is beyond this. Its about that ultimately if the file on which the SELECT is being performed is not open then thats an error which should create a trappable error condition.
>
>I can defend this point by saying that if I issue a SEEK() on a file which is not open I get an error. Why do I not get an error when I issue a SELECT? The reason is because VFP also has an interactive dot prompt aspect to it which, when used to do SELECTS on a table that is not open, presents an open dialog to the user and under that circumstance is useful. But not under runtime conditions in the field.
>
>The others are agreeing with you in creating properly constructed defensive code. However, an error is occuring which they cannot trap. The argument of this thread can then be stated as: should issuing a SELECT on a table that is not open create a trappable error condition or not? If "yes" then VFP is not doing that currently. If "no" then why do other table commands when issued on tables that are not open create trappable error conditions? Its not consistent.
>
>And by the way, the usual disclaimer: VFP rocks! And Fabio, lighten up. Of course there will be a VFP 11 :)