Run DCOMCNFG and mark Visual FoxPro Application impersonation as
InterActive user. This will allow you to unload the EXE. You can
also create your ASP application in a 'separate memory space' which
can be configured in IIS 4. If set in this fashion you can unload
the application and any client COM objects.
However, your problem is more severe. You have a hanging reference
somewhere, most likely related to the FXP loaded into memory or
possibly some of hte code running inside of it. the hanging ref
causes the COM object to not unload. You need to fix this or
you'll cause major problems with resources.
Furthermore, it's not a good idea to use VisualFoxPro.Application
because it's an EXE server. You should use custom InProc objects.
+++ Rick ---
>I had to repost this because the code did not
>print since I was using ASP\VBS and I guess
>so do UT.
>
>I tested using VFP from ASP\VB Script on NT IIS
>using the following code with success:
>
>set oFox=CreateObject("VisualFoxPro.Application")
>oFox.DoCmd "use c:\temp\hold"
>oFox.DoCmd "close all"
>oFox.Quit
>SET oFox = NOTHING
>
>I tested using VFP from ASP\VB Script on NT IIS
>using the following code with success
>(the program actually ran!!!):
>
>set oFox=CreateObject("VisualFoxPro.Application")
>oFox.DoCmd "DO C:\TEMP\TESTWEB.FXP"
>oFox.Quit
>SET oFox = NOTHING
>
>But now there are a bunch of VFP.EXE in the NT's
>Task Manager that won't go away. In the Task Manager
>I hit
but nope, it gives an "Access Denied"
>messages.
>
>Anyone know how to get rid of VFP.EXE from still
>being a process if the above code doesn't end
>the process?
