>We will try this again..
>
>This is not an accurate way to test your automation servers. It would be better to instance them in something other than VFP - like Excel, VB, or in a client-side script in IE. I have seen where VFP treats servers it creates differently in its (VFP that is) context than in something else.
>

John,

You have a valid point. I did actually test them from Internet Information Server & ASP as well, but obviously not enough.... Seriously, I think this is SYS(3050) or something else related, not MTS but...

>Is the DLL created actually in the MTS package? Once again, I think you are going to run into problems because of the compatibility issues between MTS and VFP 5.

I think I may have confused things by mentioning MTS. I am not, and do not claim to be, an MTS expert. However, basically what happens is that a Virtual directory on the Web Server has been created to house the ASP files and the FoxPro .DLL/TLB/VBR files. When you create an ASP application using the (IIS4) microsoft management console, you have the option of marking the ASP application to run in it's own memory space (this enables DLLs to be unloaded which Is why I went for it). Up until this point, I don't know what (if any) influence MTS has. However, once you mark it to run in it's own address space, a package is automatically created in MTS for the virtual root ASP directory. From now on this ASP application (including any DLL calls) run in their own separate MTX.EXE package - you can see it from the NT Server Task Manager - and is managed by MTS. I have configured the package to run in the context of the Administrator account, thereby giving the FOX DLL/ASP pages access to all the resources it needs (as I said If I could have got ASPOutOfProcComponents METABASE key in IIS4 to work, I could have used an .EXE-based server configured with DCOMCNFG to do roughtly the same thing).

You mention compatibility issues, and from what I've seen of all the pre-VFP6 hoopla "MTS" compatibility is always mentioned, which seems to implicitly state that VFP 5 is not compatible...however I know for a fact that other people will be doing the same thing as I am (one of my other VFP DLL applications has been running for 6 months this way, PERFECTLY!). What are the stated incompatibilities...? is is purely to do with apartment threading issues or something else?

>FWIW, in the context of DLL's, I would guess SYS(3050) is applicable. If the application that instances the DLL is in the foreground, since the DLL runs in the same process space, my guess is that VFP is also part of the foreground. I could be wrong here since I have never tested it. In any case, it is something worth investigating.

The DLL is called by the ASP CREATOBJECT() method in the GLOBAL.ASA IIS ASP configuration page. because it runs in a separate memory space, I guess that it "belongs" to that particular MTX.EXE package (in the sense that it runs inside that process space). However, as there's no user interface on the NT Server - you can see the MTX.EXE in the task list but do not interact with it like you do while developing software interactively with VFP - does it (MTX.EXE) ever come to the foreground?

>In your DLL, I would suggest setting SYS(3050,1) and SYS(3050,2) to different values to see what happens. The FoxTalk article should be a good guide.

Yes, it's an excellent article that everybody should be forced to read - in fact, MS should put in the VFP6 online help unless they have changed SYS(3050)'s usage in VFP6.

One question. If I get a SYS(3050,1) setting that works for me, is it wrong to set the value of SYS(3050,2) to the same value? I mean If I can afford to allow (say) 40MB - remember the NT Server has 256MB - for SYS(3050,1) why should I set SYS(3050,2) to say 10MB when It could be set to 40MB.

>
>Often, there is no science to any of this - it is trial and error.
>
>Good luck

Thanks.

It's quite new territory, and the fact that I am using ASP, IIS, MTS, VFP, NT, etc means that when things go belly up there's more culprits to blame than there ever used to be, and it could be any (all or some) of them at fault!

Regards,

Alastair