Jim,

> this is a plain vanilla VFP class
> SET CLASSLIB TO bizObjsLib.vcx
> oPrimeKeys = CREATEOBJECT('bizDataManager')

1) An object.Name property has no relevance to the memvar holding the object reference.

2) An object.Name has relevance in the context of containership hierarchy (ala dropped on a form or runtime contained via AddObject(), but not really any context for createobject() objects which have no containership hierarchy.

So the oODBCManager is responsible to destroy all of the bizDataManagers that registered with it? What is the scope of oPrimeKeys? What sort of code uses the oPrimeKeys object? In VFP an object won't destruct as long as there are object references to it, so if oPrimeKeys refers to the object and oODBCManager also refers to it the object can't destruct until both references are removed.

One way to approach would be to let oODBCManager use a factory method to create and hold all these objects itself as AddObject() items or in an array property.

to create it:

oODBCManager.AddDataManager( "oPrimeKeys", "bizDataManager", "bizObjsLib.vcx" )

the AddDataManager method:

lparameter pcName, pcClass, pcClasslib

set classlib to pcClassLib additive
this.AddObject( pcName, pcClass )

using AddObject makes it a contained object, so that when oODBCManager goes away it takes all of it's contained objects go away.

To use oPrimeKeys you could call an oODBCManager method and it would delegate the call to the right object oODBCManager.MethodX( "oPrimeKeys" ). Or you can access it like oODBCManager.oPrimeKeys.MethodX(), but this violates the encapsulation of oODBCManager a little more.

I typically use sys(2015) to create unique "names" for items that register with each other. So the registree set it's own property to uniquely identifies itself and then the registerer keeps track of that name in order to "find" the registree later. I like using names because they prevent deadly embrace object refererence situations, but they do cost a little more when you have to find the object. If you are making lots of calls and performance is an issue use a direct object reference along with the necessary cleanup code on both sides to clear the references.

>In the Init event of bizDataManager I have code that 'registers' the object with another object called oODBCManager so that when the oODBCManager object gets released then all data manager objects registered with it will be released in its Destroy event. That way I don't have any little orphans running around looking for their mamas and daddies trying to do whatever...
>
>All that being said, I now realize that I can pass a parameter in the CREATEOBJECT() command that names the new instance of the bizDataManager so it can do a THIS.Name = m.tcInstanceName and then go ahead and do the registration routine with the oODBCManager object. But it seems to me that this should be available already with the instance. Guess not. I'll keep looking but this work around should do the trick.