Yes, you and Sergey are right! How stupid of me. Looking in my original code, I now see that I called the EXE with my routine that uses ShellExecute. Somehow I forgot my own original implementation requirements and called the exe this time directly. With additional testing, the result would indeed have been 'feature not available'.

>If exe is called directly (by do command) by another exe it acts as it is sharing the original exe's environment.
>
>We encountered the same problem when we forgot to upgrade our launcher program. The main exe was in VFP9 but the launcher was in VFP8 and we got feature not available (or error, I forgot) running some new commands in VFP9.
>
>>I've built a VFP9 EXE that takes a script and executes it. The script is produced in a VFP7 built app and then the VFP7 app calls the VFP9 EXE with the command to execute the script. This way various VFP9 specific features can be used in a VFP7 application.
>>
>>I had expected the EXE to be a completely standalone EXE. However, I discovered that the EXE actually continuates in the same environment. The consequence is that it has access to the open tables (ha, that's sounds good), knows the various settings, private variables (wow) and so on.
>>
>>Yes, I should have known better. Calling an EXE is similar to calling an APP indeed. The 'solution' here is to call the exe with the RUN command. In that case it will indeed act as a completely standalone exe.
>>
>>But hey, it opens entirely new possibilities also. I had to code the script quite extensively. For example, I had to make a copy of a table to the folder for temporary files first and then specify in the script it had to use that table. Instead, I can simply specify in the script to use the already opened table, etc.
>>
>>But I'm not sure this use/abuse goes without a price. What can be expected? And how about an APP built with VFP9? Would that one also work asif it is VFP9?