Thanks for all of your help. It's much appreciated.

Unfortunately I didn't get to your seesion at DevCon. Now I'm wishing I had...

I did actually try returning an object that had an array as a property but got the same problem. However, through different testing I found a potential error in one of my method calls when two simultaneous calls were made. The difference seems to be that when running as an EXE, the error (which I trap for using COMRETURNERROR()) gets passed back properly. As a DLL picked up by MTS, it trashes ASP. I think this is what they mean by "process isolation". I should know for sure by tomorrow.

I was also getting ready to try the test you were mentioning but it may not be necessary now.

By the way regarding CreateObject vs. Server.CreateObject: CreateObject alone is (I believe) older VBScript syntax. The difference seems to be that it creates the object in the thread that calls the CreateObject instead of using the pool provided by ASP/MTS. The way I can tell this is because I use an ODBC connection in the object I keep talking about. When I look at the current activity using Server.CreateObject, the "owner" of the activity is Transaction Server Explorer. When I use CreateObject alone, the owner is "sa" - the login.
This may have an interesting implication or two.

By the way, if you decided not to use ASP/VFP, what did you decide on? FOXISAPI, VB, whatever? I'm going to check out some of your company's products as well.

Again, thanks for the info.

Eric Shaneson

>>The problem that I'm having may actually be related to the fact that I return an object to the ASP page - which you should be able to do over the COM layer. The object is a "collection" - actually an array of objects. I'm going to try it returning simple data types instead to see if that's what's breaking it.
>>Regardless, if it serializes method calls it's still not going to be very efficient.
>
>I've never been able to get array returns to work reliably. This is most
>likely what your problem is. There's a simple workaround though: Return
>a single object that has an Array member. This works fine - I have several
>VB apps that call VFP InProc COM servers in this fashion and it works well.
>
>>I got the idea of the single-use EXE from a message that you posted. I'm not sure what you mean by "all COM access siezes". I had to make a few changes to my code but I compiled it as a single-use EXE. Then I used Createobject (instead of Server.CreateObject) to create the objects.
>
>Take a look at the Active Server Documentation and look at how objects are
>instantiated. In 5.0 EXE was the only way you could run VFP objects reliably,
>because of the problems with the overlapping globals in 5.0. It was a bad
>idea, which is why I have to date never installed a live ASP application that uses VFP COM objects.
>
>EXE Servers loaded off Server.CreateObject cause a global lock on the COM
>object manager in the Server object which means while your method is running
>it's locked and can't do anything else.
>
>Not sure what you mean by CreateObject on its own. I don't think that's supported (I may be wrong, but I think I actually did that by accident
>last night).
>
>>What happened was interesting. Of course, I got multiple instances of my class instantiated (multiple EXE's in Task Manager). Performance for each call was a good deal slower on average, because of course each thread was instantiating it's own object from it's process. But it didn't seem like the method calls were serializing. Performance stayed the same or similiar from each client regardless of the number of copies of the library that had been loaded. When I ran a test of a page that essentially created and released the object 100 times from 3 different clients, all three took about the same amount of time (within 10 seconds). As well, if I had one of these processes running and I ran an interactive page that created and released the object once, it performed the same as if the process wasn't running.
>
>Performance is hard to measure that way and I'm pretty sure it was serialized.
>The only way to know for sure is write some code into your servers that check
>for that by running a long and a short request in close succession and seeing
>whether the short one returns first.
>
>Either way. I find that worthless as well even if it did work - the overhead
>of loading a new instance of VFP will kill your server with even minor load.
>
>>Why would COM access sieze if the thread spawned by ASP was creating it's own instance of the object in a separate memory space? I understand that the objects won't be "shared" but I'm not sure why they would conflict. Is there something fundamental that I'm not understanding about COM?
>
>It's the way that the Server object works (at least that's the way it's
>documented - I haven't tried this recently simply because it doesn't
>really matter much). It doesn't spawn new threads - it runs a pool of
>threads for COM objects, some of which are actually cached. Whenever
>an EXE is encounter it looks the pool down. All object references you
>get are indirect references (proxies) and the server object controls
>the access.
>
>>It's really frustrating that they shipped VFP 6.0 broken in this way. No one even mentioned this problem at DevCon. Did they just figure that we wouldn't get around to trying it out?
>
>It was mentioned in the bonus session I believe and I discussed it my
>Web sessions.