>I may be weird but sometimes I really think like that when I'm writing code. It's like my little alter ego or whatever is running around in there doing what I tell it to do. I did have a little laugh as I was composing the problem and asking for help. It just fell out that way.
>
>As far as AINSTANCE() I'll give it a try. But I think I've found a workaround by simply passing the name of the instance as the parameter of the CREATEOBJECT() function:
>
> SET CLASSLIB TO bizObjsLib.vcx
> oPrimeKeys = CREATEOBJECT('bizDataManager','oPrimeKeys')
>
>A little kludgy but it'll work. This way it can set its own name to 'oPrimeKeys' then go ahead and do the registration routine with the other object.
>
>Jim White


You do realize that in an Event or Method of oPrimeKeys, that oPrimeKeys and THIS are referring to the same thing. For example:

oPrimeKeys = CreateObject( "bizDataManager", "oPrimeKeys" )

' Not sure where your ODBC object comes from, buts lets say it looks like this:
oOdbcManager = CreateObject( "SomeClassName" )
oPrimeKeys.fRegisterMeWithOdbcObject( oOdbcManager )
Return .T.

Define Class bizDataManager

   Function INIT( tcInstanceName )
      This.Name = tcInstanceName
      Return .T.  && Allow object to be instantiated.

   Function fRegisterMeWithOdbcObject( tOdbcManager )
      Local oMe As Object
      oMe = Evaluate( This.Name )
      tOdbcManager.SomeAddMethod( oMe )
      Return .T.

EndDefine

is functionally identical to

Define Class bizDataManager

   *- No need to store Instance variable name in This.Name

   Function fRegisterMeWithOdbcObject( tOdbcManager )
      tOdbcManager.SomeAddMethod( This )
      Return .T.

EndDefine

How does your ODBC object store the reference to the oPrimeKeys object? For example, is it in an array or a set of properties?

David's suggestion of using oODBCManager.AddObject() makes the most sense, because then the oPrimeKeys object can refer to the ODBC object simply using This.Parent