>It's well known fact that VFP SQL Engine never uses already opened tables/cursors. They're opened under other aliases similar to USE...AGAIN...ALIAS, used in the query and closed afterwards. See http://www.berezniker.com/content/pages/visual-foxpro/queries-and-functions-which-accept-alias-parameter.

Thanks for the info, Sergey.
However, it may be well known to you, but it's not documented, neither in F1 nor in the Hacker's Guides.

>VFP always first looks for any file inside EXE/APP and only if it cannot be found, looks for it on the disk.

Okay, it's good to know that this is the sequence rather than the other way around. Having concluded that, I must tell what I saw happening:

The error message reported the table's name INCLUDING THE PATH. How could it know the path?! It must have been SPYING in the information about the OPEN tables, as available in memory. It would have been piece of cake for the programmer to conclude that it was okay to use the obviously somewhere included (and thus readonly) and already open table.

Oh well, we'll have to live with it. Problem is I cannot think of a simple workaround.


>>The EXE contains tableX INCLUDED.
>>The EXE also has a routine that can open this table.
>>
>>In a module (a seperate APP) that routine is called.
>>After having called that routine, the table is indeed the current alias.
>>The next step is a SQL-Select statement:
>>

select * from tableX into cursor whatever

>>However, tableX is not found, although it is even the currently selected alias.
>>
>>It is apparently the case that the SQL-Select code is trying to access the physical table, even though it is already open. It can't find the physical table and then tries to locate it in the current module (APP or EXE). It is not there and so it comes with a message.
>>
>>Why is this odd behavior not documented? Why isn't it even mentioned in the Hacker's guide? Am I missing something here?