>>I have not time, now, to test this, but,
>>for a exe's included table, what is it the DBF(openAlias) fileName ?
>
>Fabio,
>
>I posted complete test code in the Message #1000922.

Sergey, thanks, now a more extensive test is simple.

This show many issues with repackage tables.

CLOSE TABLES ALL
ccBUILDACTION_BUILDEXE = 3
lcProject = "testxx"
CREATE TABLE MyInternalTable (dummy c(10))
APPEND BLANK
USE

TEXT TO lcMemoText NOSHOW
	SYS(2450,1)
	USE MyInternalTable
	MESSAGEBOX(DBF("MyInternalTable"),0,"The table filename is incorrect, best a empty/null name")
	
	SELECT * FROM MyInternalTable INTO CURSOR MyInternalTableCopy

	* ATTENTION !: SAME DBF NAME: it is a filter again alias
	MESSAGEBOX(DBF("MyInternalTableCopy"),0,"same bad name")

	* ERROR: Now: surprise: Error 1815 !!!! 
        * this look a issue with package tables, VFP9 cannot use it normally
	SELECT * FROM MyInternalTableCopy INTO ARRAY DUMMY

	* try to force VFP to build a true temp cursor R/O: 
	* this show a BUG into the Error message, INTO TABLE is not necessary !!!
	SELECT * FROM MyInternalTable INTO CURSOR MyInternalTableNoFilter NOFILTER
	* 
	MESSAGEBOX(DBF("MyInternalTableNoFilter"),0,"finally, this is a true filename")
	
	* try to use it now is ok
	SELECT * FROM MyInternalTableNoFilter INTO ARRAY DUMMY

	* ERROR: FILE NOT FOUND because out of exe context VFP search the gost dbf table
	EXECSCRIPT("SELECT * FROM MyInternalTable")

	* ERROR REPACKAGE : next search the gost dbf table, 
        * but a internal flag fire the error before to open the table dialog
	EXECSCRIPT("SELECT * FROM MyInternalTableCopy")

	* next is ok
	EXECSCRIPT("SELECT * FROM MyInternalTableNoFilter")
	
	* callback found the table, 
        * -> the VFP scope context is fully bad here,
        * it is not a stacked context, but a crossed context, like two private datasessions
	EXECSCRIPT("Callback()")
	
	PROCEDURE callback
		SELECT * FROM MyInternalTable
		
	PROCEDURE callbackcopy
		SELECT * FROM MyInternalTableCopy
ENDTEXT

STRTOFILE(lcMemoText,  "testxx.prg")

CREATE PROJECT (lcProject) NOWAIT NOSHOW
loProj = _VFP.ActiveProject


loProj.Files.Add("testxx.prg")
loProj.SetMain("testxx.prg")
loProj.Files.Add("MyInternalTable.dbf")
loProj.Files.Item(loProj.Files.Count).Exclude = .F.
loProj.Build(lcProject, ccBUILDACTION_BUILDEXE)
loProj.Close()

ERASE ("MyInternalTable.dbf")
RUN /N testxx.exe
RETURN

Then on VFP9 is necessary to open a repackage table into a true file,
with somethink like

SELECT*FROM RepackageTableName INTO CURSOR RepackageTableName

BUT WITH A HARD AND IRRENOUNCEABLE CONSTRAIN:
FILE CREATION HAVE TO BE A ATOMIC PROCESS INTO A EXCLUSIVE CONTEXT!!!
but this is not a simple task !!!!

CLOSE TABLES ALL
ERASE testxx.exe
ccBUILDACTION_BUILDEXE = 3
lcProject = "testxx"
CREATE TABLE MyInternalTable (dummy c(10))
APPEND BLANK
USE

TEXT TO lcMemoText NOSHOW
	SYS(2450,1)
	* next show another issue/bug, you cannot uses select for build a INTO TABLE copy
	SELECT * FROM MyInternalTable INTO TABLE MyInternalTable
	CLOSE TABLES ALL
	* next fail
	SELECT * FROM MyInternalTable INTO CURSOR MyInternalTable NOFILTER
	CLOSE TABLES ALL
	* next don't fail, but you have a different name
	SELECT * FROM MyInternalTable INTO TABLE MyInternalTable1
	CLOSE TABLES ALL
	* try to open with a different name for build a true file
	USE MyInternalTable ALIAS MyInternalTable_
	MESSAGEBOX(SELECT("MyInternalTable"),0,"MyInternalTable alias don't exists")
	* BUG: next command fail !!, this show another bug
	SELECT * FROM MyInternalTable_ INTO CURSOR MyInternalTable NOFILTER
	USE IN MyInternalTable_
	
ENDTEXT

STRTOFILE(lcMemoText,  "testxx.prg")

CREATE PROJECT (lcProject) NOWAIT NOSHOW
loProj = _VFP.ActiveProject

loProj.Files.Add("testxx.prg")
loProj.SetMain("testxx.prg")
loProj.Files.Add("MyInternalTable.dbf")
loProj.Files.Item(loProj.Files.Count).Exclude = .F.
loProj.Build(lcProject, ccBUILDACTION_BUILDEXE)
loProj.Close()

ERASE ("MyInternalTable.dbf")
RUN /N testxx.exe
RETURN

The impression is that there are many VFP points constructed badly,
and the repackage tables they evidence them.

Fabio