>
>>What occurs to me is that even if you had control over whether or not the dialog appears, the end result is the same. You get an error if the alias referenced in the SQL statement isn’t in use. The question, therefore, becomes, “What’s the point, since the result doesn’t change?”
>
>
>No the result is not the same, if a user gets an "Open dialog box" it will confuse the user and he will call application support, if he gets an error message he will call tech support.

However, if the code is properly written, he calls no one. This is because the user, if properly notified as to what the problem is can deal with it for themselves. In either of the above cases, the end result is the same: The user calls someone, who calls the developer, who then must deal with the problem.

>
>>Now, with all due respect, I’d say that the problem isn’t with the way VFP handles this, but rather with the underlying design of your code. It’s a “best practice” if you wrote your code defensively. In other words, since you’re aware that the problem exists, design the code accordingly.
>
>
>The problem is we don't know there will ever be a problem , a program may pass all the programmer's test, Q&A and all other tests and still fail due to some external events. Defensive programming is good but over defensive is bad and makes code harder to read et maintain.

I've never stated otherwise. However, it is still a good practice to code defensively. Despite what people might think, every program can be proven to work. If, however, external circumstances cause proven code to break, then it's easy to discern that, in fact, the cause was not the code, but conditions that could not be controlled by the code.

>
>>I’ve been generating reports using SQL statements creating cursors since the early 1990’s. From the beginning, the process has always been the same. Try to open the table. If this fails, advise the user and abort the process, otherwise pass the necessary parameters to a routine that generates the cursor. This routine returns the number of rows created by the SQL statement. If the number of rows is zero, advise the user and abort the process. If the number of rows is greater than zero, call the routine that prints the report, passing the necessary parameters, such as output type, file name of the report and so on.
>
>
>I agree but $hit appends and i dont want VFP taking over when it appends, the problem is not only for cursors if a OCX is not registered on a client machine and a user tries to open a form containing a reference to the OCX, the user will be presented with an open dialog box prompting to choose an OCX!!!

If the developer has taken the care to make that the application has a proper installation program, then this doesn't occur. Proper installation is part of the territory we, as developers, have to deal with. If we don't, if we try to take shortcuts around it, then we're responsible.

>
>>By using this technique I’ve been able to vastly reduce the amount of new code I have to write. There’s one routine that actually opens the table, returning a logical value as to whether or not it was successfully opened. There’s the routine that generates the cursor. There’s a program that, via parameters, advises the user of failure of anyone of these and what the problem is. Finally, there’s a program that actually prints the report. All of these are called from a “wrapper” program.
>
>
>Thanks for the definition of a wrapper program but i guess any accomplished programmer knew that already... The question here is WHY would VFP attempt to takeover my program and ask a user what to do ?

It's simply a feature, a convenience. If you don't want it, then take matters into your own hands and code to prevent it. Ever let FPW generate its own code to open and close the necessary tables? I did, much to my regret. Nice feature, but in practical use it was more trouble than it was worth. As a result, my applications were better off.

>
>>When we debug, however, we must determine if the cause of the problem was something with the language or environment, or something that we’ve created by poor design. In this case, poor design is the root cause, not the language. I neither want nor expect the Fox team to correct problems that I’ve created by poor design. Neither should you.
>
>
>That's right but does the "automatic open dialog box" feature falls into the "poor design" category ?

Again, it's a feature. If you don't want it to occur, design accordingly.