>>>James, thank you for the stars, but I think they should be given to Sergey.
>>>he is the man who thought about EXECSCRIPT() first. After that everything was easy :-)
>>
>>I'm not sure EXECSCRIPT is the best approach here. To me setting procedure, executing the function, restoring the procedure sounds a bit easier.
>
>It depends.
>If you have a built-in function or PRG or even procedure with the same name as that external PRG and you have SET PROCEDURE to that module, VFP will execute the built-in module not the external one.
>Also to SET PROCEDURE to external PRG you must be sure that it is already compiled. I am not sure if VFP automatically compiles PRG o FXP in run-time as it does in IDE, never tested this.
>Also EXECSCRIPT() is on line of code a little slower but not much.

Also, one must consider if private datasession are in use. If the calling routine is a method in a Form with a private datasession, then the called routine will not be able to see the tables and cursors openned in the Private DataSession of the form. While in the externl procedure, it is being executed in the public datasession. To avoid this, the datasession ID needs to be passed to the external and a SET DATASESSION statement is needed to change to the one the form is using. This one has bitten me a few times when I refactor's method into commonly shared procedures external to the form classes. This is one of FoxPro's gochas.