Yes, that's exactly what I've already tried. On my machine I get an error: "OLE error code 0x80020006: Unknown name."

I think it has to do with the VFP7+ Session object hiding certain PEMs: http://msdn.microsoft.com/en-ca/magazine/cc302029.aspx

>Have tried adding...
>

>Procedure Destroy
>      DoDefault
>endproc
>

>
>to help expose it.
>
>>Suppose I have an EXE COM server, based on the Session object, defined as follows:
>>

>>DEFINE CLASS FLocker AS Session OLEPUBLIC
>>	* DataSession = 2 (Private Data Session) is the default for the Session class
>>	
>>	FUNCTION Init
>>		SET EXCLUSIVE OFF
>>		SET TABLEVALIDATE TO 0
>>	
>>	ENDFUNC
>>	
>>	FUNCTION TableLock ( tcTable AS String, tcAlias AS String ) AS VOID
>>		USE ( tcTable ) ALIAS ( tcAlias ) IN 0 SHARED NODATA NOUPDATE
>>		=FLOCK( tcAlias )
>>	
>>	ENDFUNC
>>	
>>	FUNCTION TableUnlock ( tcAlias AS String ) AS VOID
>>		UNLOCK IN ( tcAlias )
>>		USE IN ( tcAlias )
>>	
>>	ENDFUNC
>>	
>>ENDDEFINE
>>

I can invoke the COM server with something like
>>

>>loEXECOMServer = CREATEOBJECT( "MyEXECOMServerName.FLocker" )
>>

and the COM server is created properly, works fine, and duly appears as a separate process in Task Manager.
>>
>>To release the server when I'm finished with it, until now I've just been issuing
>>

>>RELEASE loEXECOMServer
>>

which seems to work - the process disappears from Task Manager. Is this "best practice" for RELEASEing COM servers?
>>
>>Somewhat related, apparently the Session object hides "intrinsic" properties and methods by default, so as not to pollute the .TLB file. So, with this class, even if you define a .Destroy method, you can't call it from the calling program e.g. loEXECOMServer.Destroy( ) throws a COM/OLE error. But, any specified .Destroy( ) code does run when the object is RELEASEd as above.