>>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.
>
>In light of what Sergey said,
>why don't you change the alias to something different than table's name, and select from that alias?

This doesn't help.

>Or try some other trick (copy out the table, select from it into a readwrite nofilter cursor then close the table) - anything to sever the connection between the cursor you're selecting from, and the included table. SQL obviously can't pull records from a table included somewhere out there, but it should be capable of doing that from a RW cursor.

This helps:

select tableX
copy to temptable
select * from temptable into cursor whatever
use in temptable
delete file temptable.dbf
select whatever

This simple one might be done by a generic routine. But it are the clauses of the Select-SQL statement that will vary. A parameter could be used for that.
If passing a parameter is part of the solution, a better alternative may be to make a function that does the Select-SQL and include that function IN the EXE. I think I'll gonna give that one a try.