>We are so fixated on it because that's what VFPCOM does. It does not USE the table, it just sees the one that is open in the current datasession of the VFP process that called it. This is not everyday COM stuff.
>
Right, the COM Component USE's the table and uses VFPCOM to create the ADO Recordset.... It is the ADO Recordset that crosses the boundaries.
Why are we having this debate???...< s >
>This thread originated with "how does VFPCOM do that?". This question was asked so that the asker could write some functionality similar to that, and so far, the question has not been answered.
>
Right, how does VFPCOM create ADO Recordsets from VFP Data and vice versa. It is no different than the VFP procs Ken Levy created 2 years ago...
>>That is the most basic I can make the scenario....
>
>Except that the scenario you have presented does not address the question. Try this to make it even simpler:
>
>DEFINE CLASS TestCOM AS Custom OLEPUBLIC
>FUNCTION GetRecCount
>LPARA tcAlias
>SELECT (tcAlias)
>RETURN RECCOUNT()
>ENDDEFINE
>
>Compile this into a COM server, and call it from VFP's command window:
>
>USE c:\SomeTable ALIAS SomeTable
>oTC = CREATEOBJECT("TestCom.TestCom")
>lnRecCount = oTC.GetRecCount("SomeTable")
>?lnRecCount
>
>It doesn't work, because Datasession information does not cross COM boundaries, but somehow with VFPCOM, it does. That's the question.
Right, and the answer is, "you cannot do that".... that is why you use ADO Recordsets...
Done...
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement