>>>One COM object is calling another one. The method called in the 2nd COM is opening a table. When the call returns back to the 1st COM, the table opened is no longer in the scope. Is there any workaround for that?
>>
>>The datasession doesn't cross COM boundaries - if you need to share data between two COM objects, pass an ADO recordset.
>
>Have you ever tried that with PHDBase? :) I don't think it'll work. This relates to isolating the PHDBase process into a COM because of an actual problem of PHDBase. So, the object is to process the searches only. And, the actual syntax of PHDBase won't support that. Unless someone has found a way.

I've never tried using PHDBase with an ADO recordset, and frankly given the problems I've heard of, would not try using it in the scenario, but I know you can't have the same datasession under access under a VFP session and an instance of a VFP COM server, either in or out of process. You could try the following things, working against the same base table in both the cleitn and server: (1) Try creating a cursor in the COM object, and then passing that back as an ADO recordset or XML string with the query result, and use the result as a separate thing from the table itself. Or (2) if PHDBase can be used to create a filter condition for an .IDX, use PHDBase to perform a search against the table as part of an INDEX TO performed in the server, creating an explicit .IDX that filters the tables based on the results of the PHDBase search. Close the table in the COM session (or at least release the reference .IDX created via:

SET INDEX TO
FLUSH

to make sure it's closed and actually written to disk), pass the name of the .IDX created in the COM session back to the caller, and then apply the filtered .IDX created in the query to the original table on the other size via SET INDEX TO returned name of filtered .IDX file ADDITIVE.

Sounds like time to move away from VFP native tables and relying on PHDBase.