>>Just the act of attempting to verify the existence of the object would probably cause the same problem.
>
>Actually, larry when i disconnect my network, Type("ox") still return "O" with no delay.

When you do this, you are not making a COM call, you are checking the data type of what is stored in the local machine's memory space. In order to ascertain whether an object actually exists, you have to query its members.

The same behavior can be duplicated locally by instantiating something like Word. Then launch Word from the menu (or Office toolbar). Word will not create a new instance, it will just make the instance used by VFP visible. Now exit Word.

type("oword") returns "O"
isnull(oword) returns .F.
vartype(oword) returns "O"

But Word is not really there. In order to make sure Word does exist, you have to do something like check the Name property.

type("oword.Name") returns "U"

This is relatively fast because we are making a local COM call. Where as your call takes minutes because it is making a remote COM call and it has the added overhead of going through a network connection that doesn't exist anymore.

Because Windows has to go through it's "I tried to connect, I timedout, I retried and timedout multiple times, okay let me return an error", it takes you a while to see the results.

One suggestion is to try and create another connection (separate from the COM instance) to the resource that holds the server. You can use Ed Rauh's WNetAddConnection2 example (located in the Files - WinAPI section as Netresource). If it returns a valid connection, you know the network is okay and it is okay to try and access the COM server. If it fails, you'll know if had to do with the COM server and the return should be relatively quick.

Although, I haven't tried this, the theory behind it is a new connection attempt may fail faster than a connection that already existed. If the connection fails, then you can set your variable to .NULL. and go on your way.