This does not help. The reference of dbf() is to the original location at the time of the build of the EXE. That location does not (necessarilly) exist at the time of the execution. Or the table is no longer there.
>
>select * from dbf('tableX') into cursor whatever>
>>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?
Groet,
Peter de Valença
Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.
