Fabio,


#1. I agree that value returned by DBF("MyInternalTable") for embedded table is misleading. I would expect the table name w/o path.

#2. Yes, it looks like USE AGAIN. The result returned by DBF() is again missleading. Adding NOFILTER creates a cursor with temp file name.

#3. Looks like a bug to me. We should be able to reference a cursor by its alias regardless how it's created.

#4. After thinking about this situation I came to conclusion that it also looks like a bug. We should be able to reference open table or cursor because VFP knows about it.

I didn't look into the rest.

>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
#1
>	MESSAGEBOX(DBF("MyInternalTable"),0,"The table filename is incorrect, best a empty/null name")
>	
>	SELECT * FROM MyInternalTable INTO CURSOR MyInternalTableCopy
#2
>	* ATTENTION !: SAME DBF NAME: it is a filter again alias
>	MESSAGEBOX(DBF("MyInternalTableCopy"),0,"same bad name")
#3
>	* 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
#4
>	* 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