>[Snip...]
>
>>I don't know much about DCOM other than what I've read in articles, but I thought DCOM was supposed to make objects available for use no matter where they are (local or network) in a transparent fashion. Using a new function specifically for Remote Objects seems to fly in the face of this. Is there something I am missing, or is this yet another kludge to get something to work in VFP that already works in other MS products? Thanks for any insight you can provide.
>
>
>
>VFP will work fine with DCOM as other products do. What VFP 6 offers is an ADDITIONAL capability... The ability to instantiate an object and specify which machine it will instantiate on (thereby overriding the registry settings). I can see this as being *very* useful for apps that have top scale real big.

On a side note on COM. I talked to Randy Brown of Microsoft and he said that VFP6 will NOT provide non-blocking COM objects. In other words every request to an instanstiated VFP COM object will not be processed if there is a previous request already being processed by the object. I thought MS Transaction Server was going to do away with this limitation but it will not. This makes VFP COM objects completely unscalable and unusable as 3-tier business objects!!! I cannot believe the Microsoft VFP team thinks this is acceptable! ( Sorry just venting a bit.. ) Do you have any insite on this?

Thanks in Advance.