Mike,

My apologies for the curt reply. Peace?

Let me run down a few things that I tried before posting.

1. First was the CREATEOBJECT from fox, just to make sure my class was no cracked. I did Rick Strahl's original "Hello World" class, and was able to create the object and get the expected response with

oTemp = CREATEOBJECT("FoxTest.Foxtest")
? oTemp.HelloWorld()

2. Knowing that the class was OK, I checked to make sure Fox was up at SP 4, since I have recently rebuilt my machine. OK there, I had remembered to put in SP 4 a few weeks back. (Don't really know if this matters, but we always want everything current).

3. Beginning to suspect it was FoxISAPI.dll, I went to MSDN.Microsoft.com and found the Jan 2000 version, and put that into scripts. Still no go.

4. I then reread the MSDN doc (past the Foxweb example) and saw the FoxISAPI commands like "Status" and stuff. I thought, "aha, a way to test FoxISAPI itself and narrow down the problem." I tried http://localhost/scripts/foxisapi.dll/Status and got the 500 error. Tried the more explicit http://192.168.0.1/... and no go. Tried my actual web address as well, no go, still getting 500 error.

5. Again, since this is a simple example, I began to lean heavily on the idea that my environment must be hosed. Since I do a lot of experimentation, I figured, "Let's make sure there is no quirky security setting left over from one of my experiments," and set permissions on the entire NTFS volume to Full control for Everyone, with a cascade down the entire tree. I figured this way no chance that somehow I had locked my own web server out of necessary folders. No go.

6. FWIW, between each of these I shut down the IIS server, then restarted it, since the docs specify that once FoxISAPI is loaded it stays loaded, and I know from lots of coding of Fox COM objects for use on the web that those babies are "sticky," once IIS loads them they have to be right or its a big PITA to shut everything down to do a recompile.

7. I have not yet done this next step, which is recompiling FoxISAPI from the source, since I don't yet have a serious justification for doing so, and am likely to get bogged down in C++ for a couple of hours.

8. It was at this point that I searched MSDN online for FoxISAPI+2000, wondering if there was a known issue with Win 2000. Finding nothing, I placed my original post here.

9. Have since also search the fox wicki site, but it is also full of docs which imply the simplicity of the whole thing, and this further convinced me that it must be my machine. So at this point, I do not know what to do with my machine.

Thanks for the holiday replies.

>
>1. Test in VFP by creating a non-COM object from FoxWeb. Something like

ox=newo('server')

right before the class definition.
>
>2. If that works, compile and NEWO('foxweb.server') on the COM server.
>
>3. If that works, then you're right, something's hosed in your environment. I tend to doubt it, though.
>
>> I followed them and it did not work. Since everyone else follows them and they do work, then I must assume that either a) I have configured my machine in some way as to prevent these normal operations, or b) there is some known issue with Windows 2000.
>
>It ain't b), because I test weekly on Windows 2000. There is the remote chance that the COM server is crashing (this can cause a result of 500). The above steps will help you determine this.