Wow, I just read this thread looking for a solution to something else and I have to say that I'm a bit overwhelmed.

When I read the first post from Fabio, I immediately understood that he was writing some sample code that reproduced a problem - not submitting it for critique. Although, the post did appear more like a criticism of FoxPro than a request for help which is, I'm sure, what garnered the ire of so many. However, I'm a bit disconcerted at how quickly the thread degraded into "if you weren't so lazy and you wrote/tested your code properly, you'd never have this problem." I don't think that was ever the issue.

I have encountered this behavior numerous times over the last 15 years. I know that it's inherent to FoxPro. I myself have seen it and coded to avoid it since FoxPro 2.0. The open dialog appears not just in SQL statements. It appears any time you try to execute a command that requires a table/cursor and one is not open. It makes perfect sense when working interactively within the command window, but none whatsoever inside an application. Inside an application, if a table is not open when you try to execute a command that requires one, it's an error - plain and simple. It's almost always one that the programmer could or should have anticipated and handled, but an error nonetheless.

It has been hotly debated in this thread as to whether or not this condition is an error. David's point about this being documented behavior for SQL statements is well-taken and quite correct. However, it is not documented for most database commands. (Try finding it for SKIP, COUNT or SEEK.) As I said before, if a table is not open when you try to execute a command that requires one, it's an error.) The VFPT must agree as well, because FoxPro certainly DOES generate an error - AFTER displaying the dialog box.

If such a situation occurs within an application (as opposed to the command window) there is no benefit that I can think of for displaying the open dialog unless the user of that application is familiar with the tables in the database and knows what table the app expects to be opened. That is almost never the case with a production application. (Whether or not it is good practice to write an app that relies on this open dialog box is a completely different discussion and NOT one that I wish to go into here.)

Personally, I believe that FoxPro should never have been designed so as to allow this behavior to occur inside an application. Be that as it may, FoxPro WAS designed this way - and well before Microsoft bought it. I also believe that, because it was designed in this manner, there are applications out there that use it, so backward compatibility IS an issue - like it or not. So, as David pointed out, to change the behavior would require a SET statement. I would whole-heartedly support and vote for this change as I can think of a few instances that would be more correctly handled by using it.