Hi George.

>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.

I've to strongly disagree with you. The issue is exactly about VFP not giving a developer a choice how to handle situation when required table cannot be found/open. I don't belive that you've any applications in production that allow Open Table dialog to popup because it would be unprofessional looking.

>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?

The best solution would be to give a developer a choice between poping up a dialog and triggering an error, with existing behavior as default.

>
>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.

I can agree with you about developers responsibility to "to deliver a product that works as both I intended it, and the user wants". However it's irrelevant to the discussion at hand. I personaly would prefer that VFP team make changes to the product and give as control over VFP behavior in such cases.