That'd work...then I'd get that table into a cursor so the data would be local. I am doing this now, so this would be a quick change...I won't have to change all my HistClaimCursor references to &cTable (or whatever)...

Thanks for the input John.


>Hi Joseph ---
>
>In that case, use SYS(2015) or another function to create a temp filename unique (sort of) to the calling machine..
>

>cTable=SYS(2015)
>oSalesInfo = automation object instantiated on frontend
>nSuccess=oSalesInfo.SalesbyState(cTable)
>IF nSuccess = 1
>   USE (cTable) IN 0 SHARED
>ENDIF
>

>
>
>
>
>>How do you get around the problem of multiple users wanting the same table? I am assuming that statetemp.dbf is on the server machine...
>>
>>
>>>Hi Joseph ---
>>>
>>>Did I accidently get CCed with this or was it intentional. I don't mind either way....
>>>
>>>What I have done in the past with a VFP front-end and VFP middleware is pass a tablename to the automation object and have the automation object send back a success code. If successful, I can assume that the automation object has created a table with the name I specified....of course, you may want to CLOSE the new table in the Automation object before returning control.
>>>
>>>For example:
>>>

>>>oSalesInfo = automation object instantiated on frontend
>>>nSuccess=oSalesInfo.SalesbyState("statetemp")
>>>IF nSuccess = 1
>>>   USE statetemp IN 0 SHARED
>>>ENDIF
>>>

>>>
>>>As to passing back an entire temp cursor or view.....no idea.