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

Jos,

With all due respect (and it’s considerable), I must disagree. This isn’t an issue regarding VFP, but rather, on the most fundamental level, taking responsibility. Please allow me to elaborate.

One part of the problem is that until the SQL statement is parsed, VFP has no way to know what alias is referenced. By presenting the dialog, it cannot know until the user/developer makes a selection. After the selection is made, it then generates an error if either the user clicks the Cancel button or, worse, selects the wrong table. The best solution would be to remove the option to select the table. OTOH, how much existing code would be broken if VFP did not try to open the table?

I, as well as most VFP developers, am aware of this behavior. It’s my responsibility to deliver a product that works as both I intended it, and the user wants. I look at the fact that VFP will automatically open the table in an SQL query as a convenience, a feature, if you will. Does this mean that if I use this “feature” that I’m not responsible for the result? No, to the contrary, I am directly responsible.

This thread has focused on only a half of the problem. It hasn’t addressed two other significant possibilities. First, what if the user, when presented with the dialog, doesn’t select the correct file? Most likely, the SQL statement generates an error. At best, the wrong results are returned. We’re, as developers, not supposed to evaluate the “best case” conditions, but rather the worst. Second, what if there’s a table with the same name on the path that’s opened instead of the intended one? Again, either the SQL statement generates an error or the wrong results are returned.

Now, if I don’t rely on this “feature” and take the time and care to make sure that the correct table is opened prior to issuing the SQL statement, I don’t have these problems. I don’t have to deal with them ever! That’s why this, on the most basic level, is about “best practices”. I take the responsibility for what my code does. If I make a mistake, that’s my problem. In this instance, if the developer wants the VFP team to correct something that can easily be worked around, I say I want the Fox team to concentrate on other issues, rather than my own lack of responsibility.