>Thanks, but this is one absurdity.
>VFPT cannot put a little little flag for to inhibit this ?
>I must add tons of test for skip it.
>
Fabio,

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

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.

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.

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.

In coding in this manner, each of the routines is functionally cohesive. They do one thing and one thing only. As I said earlier, this allows me to not only reduce the amount of code necessary, but also greatly reduce the possibility of errors since each of the routines called has been tested previously and has been proven to work as the design intended.

Many people don’t properly understand the difference between the terms “testing” and “debugging”, thinking that they are one in the same. They are not. When we test, we deliberately try to “break” a program. When we debug, we try to find the root cause as to why the program “broke”. You’re good at testing. The other day you pointed out to me that one of the functions I posted was incorrect. The reason that it was incorrect was that I did a bad job of both designing the algorithm and testing it. To the person who posted the question, I admitted that you were correct, apologized, and posted a correct routine.

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.