EXECSCRIPT() and Terminal Server

[baltman]

I have an app (in VFP 7) which dynamically creates a code string (series of CASE statements) and then executes it within a SCAN using EXECSCRIPT().

It works great on a local PC, but it takes forever on a remote desktop. I identified this line as THE problem with execution time increasing from 17 to 87 seconds using faq184-63.

Does anyone know how EXECSCRIPT() functions? Could it be getting hit by a virus scanner? Local machine and server have different versions of a virus scanner installed.

Are there any possible work arounds, or do I need to find a different way to apply this logic?

I have BITMAP OFF and am controlling memory with SYS(3050).

Thanks,
Brian

 

[baltman]

I can now confirm that if I use STRTOFILE() to make my string a PRG and then compile/run the PRG in place of EXECSCRIPT() within the SCAN, that the run time on the server falls from 87 seconds to 6 seconds.

I'd still be interested in what the functional difference is, why there is such a large discrepancy between the two methods, and why the problem becomes so pronounced when on a remote desktop.

Brian

 

[bobcha]

Hi Brian,

I *think* that EXECSCRIPT creates a fxp file in the temporary directory. Could the location of this directory be the reason for the slow down?

Past experience with using VFP dlls in web apps has led me to believe that VFP dlls require modify rights to the temproary path.

Cheers,
Ben

 

[ramani]

Hi Brian,

Have you tried also, by keeping the code in a memo field and doing an EXECESCRIPT()?



____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

When you ask VFP questions, please add VFP version.

 

[baltman]

pneutam,

It is possible that the temp folder is located on a slower drive. I think it is just a different partition of the same drive, but I could be wrong.

Either way, I thought a prg was loaded into memory when it is run, so subsequent calls shouldn't cause the type of performance hit I'm seeing.

Next time I get to that part of the code, I can try switching back to EXECESCRIPT() using a different temp folder to see what the effect is.

ramani,

The code that is being executed can become very large and is built dynamically by concatenating code contained in specific memo fields based on run-time filters, so building it into a string or writing it to a file is the best way to go.

Thanks for your interest in this issue.

Brian

 

[bobcha]

Brian,

I would have thought EXECSCRIPT would have been solely memory based also, but I've had it fail when the temp path was inaccessable due to security. The error was "cannot create file %\script.fxp", where % was a control character of some kind - a pretty big hint as to what EXECSCRIPT is doing.

Cheers,
Ben