Hi Christof,

Been awhile, my friend. How're you doing?
>
>>What's being requested is that a switch (most likely a SET command) be implemented so that the dialog doesn't appear and an error raised.

>Raising an error would be a good thing... I agree that such errors should have been avoided in the first place.

I don't disagree with the first part of your statement. However, I look at the fact that, if VFP can find the table with a match to the primary part of the table a "feature".

I tend to avoid "features" at all costs. If the behavior changes in the next version, I'm not stuck having to re-write to accomodate it.

Further, if the user presses cancel on the dialog, then you get the alias plus the "dbf" extension as the file being looked for. If you have tables with similar structures being used in the query, then you may or may not know the proper file name.

>However, when you run a VFP application as a service (or part of it) or as a non-interactive application, the app doesn't have access to a Windows Station (desktop) to display the dialog. Hence, if for some reason a table is not available, the application hangs and your only options are killing the app from the Task Manager potentially corrupting data files.

It seems to me that we have enough "hammers" to drive this "nail". Between creating our own routine to open the table, to private datasessions, to subclassable dataenvironments, what more do we need here?