Paul,

>>Is it possible to have a web service object maintain a persitant connection to an instance of the object on the server?<

I don't think it's possible. A Web Service method call should be stateless.

~~Bonnie


>>Paul,
>>
>>>I didn't realize this was happening until my log file was about 1.5 GB! Line 907 is:
>>> SELECT sides_hd
>>>
>>>This all works when called as a straight COM object.
>>
>>When do you USE sides_hd in the COM component? Is that also logging an error in the log file (I suspect that it is).
>>
>>Probably your COM component cannot find the sides_hd.DBF because when called from ASP as a web service, the COM object is starting up in a different directory (Windows\System32) than when you just call it inside VFP. FWIW, you would run into the same problem if you ran your COM object from inside VFP after installing it in COM+ Services.
>>
>>Try putting a full path to the DBF on the "USE sides_hd" command (wherever that is) in the COM server and see if that solves it. If you first want to confirm the diagnosis, check your error log for errors on USE sides_hd.
>
>
>I have dealt with all of the pathing issues. This is actually based on a com object I use with some asp pages. The file is opened in another function of the object. I think that I have discovered the problem, however. The tables are opened in another call. I was trying to issue the calls sequentially like this:
>
>loRestServ.OpenRestaurant("pmoon")
>loRestServ.SidesHdImport(xmlSidesHd)
>
>My suspicion is that each call to the web service object creates a unique instance of the object on the server. Therefore I can't use the first call to set up the environment and the second to perform the function. To verify this, I moved the command to setup the environment into the SidesHdImport function. At that point the function worked.
>
>So...
>Is it possible to have a web service object maintain a persitant connection to an instance of the object on the server?
>
>Thanks,
>
>Paul