>George,
>
>
>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?”
>
>
>The result changes a lot:
>i catch the error, write it on MY application errors log file,
>kill the procedure/application and out a message in italian language to my customer.

No, you still get an error that you can log. However, if the application is properly designed, then this doesn't occur at all.

>A professional application it can not output to the customer a strange english dialog for search a table;
>the result is that my customer it takes the telephone and it calls my company for knowing what to make.

However, if you properly design the application, you don't get phone calls at all. You're relying on a feature to do the work you should be doing.

>I must say he to press cancel in order to make to fire the error on my application ?

VFP has no control over the dialog it presents. It's a part of the Common Dialogs dll. How do you expect the parser to respond? It can't in the midst of trying to interpret the code switch directions.

>
>Now, with all due respect, I’d say that the problem isn’t with the way Visual FoxPro 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.
>
>
>You implement a ( wrapper ) managed code for VFP language.
>But VFP is a managed code for C language.
>C is a managed code for assembler.
>....
>
>This is obvious, but this is slow, then you implement slow x slow ---= slow^2

Ah! Well, I've never, ever had a user complain about how slow my code is. To the contrary, because the modules are only loaded when required, the actual tendency is to be faster than a single monolithic program. Further, performance problems are, in fact, a result of poor architecture and design rather than implementing proper coding techniques. This has been proven in studies time and again.

>If you are happy, i'm glad for you.
>In Italy it is said:
>"who pleases itself enjoys".
>
>
>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.
>
>For one skilled developer it does not have sense to test without debugging.
>
>
>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.
>
>
>I am completely in disagreement with you, but by now we have understood both to it, this is a fact.
>
Well, you're completely in disagreement with not only me, but quite a researchers who have hard data to contradict you. This includes personnel from IBM, Hewlett-Packard, TRW, the US Department of Defense, and NASA.