I think it's about "programming style".

It's about getting all your ducks in a row before kicking off a process, vs "open / select as we go" (and take your chances).

It's about wrapper functions / parameter driven / OOP operations, vs more "procedural" code (and "switches" and "flags").

If we were coding in a fully OO platform like .NET, we wouldn't be having this discussion.

Without a "wrapper" (or "object"), I fail to see how one can come up with a "meaningful" error routine (that avoids the "open dialog"), and conveys any useful information without coding a unique error/try routine for EVERY SELECT / whatever; ie. what was the context and what were the parameters (eg. file name OR alias, table or CURSOR, operation, whatever) that caused the error condition ? All you've got is an error, line number / statement ... maybe ... assuming you compiled with DEBUG.

It's about: Pay me now, or pay me later (again and again).

>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 :)