Hi George. My comments inline:


>One part of the problem is that until the SQL statement is parsed, VFP has no way to know what alias is referenced.

Agreed. But by the same token I can issue a SEEK() and VFP does not know if the table is open until runtime either. If its not open an error is thrown which can be trapped. But I understand your point too in that why was the program performing a SEEK() without knowing that the file was open in the first place. Good point :)


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

This last sentence is my point. I think the app should simply error out. The developer must trap for it or, preferably, have constructed the code in such a way that the condition could not happen in the first place.


>OTOH, how much existing code would be broken if VFP did not try to open the table?

You are 100% correct. Personally I dont want the VFP team to spend even a minute on this issue as I do not think it warrants any serious attention. My comments are only intended on a discussion level rather than a desire to change VFP in this respect.



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

Agree.


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

Is that not a good argument in favour of having VFP throw an error rather than asking what file to open? The user could possibly make a bad situation (code error) even worse (wrong file selection) and accept the erroneous results.


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

Good point. I had not thought about this. Its solved, as you say, by proper code development and solid testing.


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

Fully agree. Ultimately the developer needs to ensure the app works, which includes working under real world conditions at end user sites.


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

Fully agree. There are far more important developments and enhancements that the VFP team can focus on. Ultimately I think that every dev tool has some funnies, bugs, quirks, etc. We learn to work with them or around them. There is no perfect dev tool and I think VFP is certainly better than many.

Personally speaking this particular quirk is a non-issue for me becuase, as you say, I (hopefully) have coded correctly to avoid it. It is certainly not a big thing and I cannot remember the last time it happened to me, touch wood :)