Hoi peter,

This behaviour also exists with classes in classlibs. If you execute a script with EXECSCRIPT(), it can't find any classes in the executable if not already loaded.

The trick I used is to have a DOCMD() function in the exe, so you can can call DOCMD([x=CREATEOBJECT("Myclass")]). This is because from the script I go back into the executable through the DOCMD() function. Of course the DOCMD function is very simple like

FUNCTION Docmd(cCommand)
&cCommand
RETURN

So your problem can be solved if you've got a DOCMD() function in your startup prg, and call:

DOCMD("select * from tableX into cursor whatever")

Hope this helps.

Walter,



>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[