Re: Class not registered on local machine (Error 463) Clarified

[DaveSatz]

I could be much more precise - here is a simplified example of what we are
doing

We have an interface class, called iBSWrapper in the itsBSInterfaces DLL.
For simplicity sake, we'll say that the only method on iBSWrapper is
Pubic Function GetData() AS ADODB.RecordSet
End Function

itsBSInterfaces DLL is registered on the client machine and on the MTS
Server (outside of MTS)

We then have a VB Component running under MTS that IMPLEMENTS
itsBSInterfaces.iBSWrapper as has code the return a recordset in the
GetData method.

We have DLL's registered on the client machine like this (m_strAppServer is
passed in to the DLL from the EXE. m_strAppServer contains the name of the
MTS server:

Private m_iBSWrapper As itsBSInterfaces.IBSWrapper

Private Sub CreateMTSWrapper()

On Error GoTo ERROR_LABEL
Const strWRAPPER As String = "itsBSCountry.CBSCountryWrapper"

If Not m_iBSWrapper Is Nothing Then Exit Sub

If Len(Trim(m_strAppServer)) = 0 Then
' for development against local DLLs
Set m_iBSWrapper = CreateObject(strWRAPPER)
Else
' run under MTS
Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer)
End If
Exit Sub

ERROR_LABEL:
If Err.Source <> App.EXEName Then
'source was deliberately set by this proc or a proc called here, so
pass it back as-is
Err.Raise Err.Number, Err.Source, Err.Description
Else
'vb just raised this error here
Err.Raise Err.Number, TypeName(Me), Err.Description
End If

End Sub

I did not register any of the DLL's or typelib's for the DLL's running
under MTS on the client machine.

The Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer) is what is
failing with the "class ..." error message.



--
--
Thanks,
David Satz
Principal Software Engineer
Hyperion Solutions
(using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
(Please respond to the newsgroup.)


DaveSatz <davidsatz@yahoo.com> wrote in message
news:39109cb6@news.devx.com...
> I get this error when I try to use Set objectvariable =
> CreateObject("progID", ["servername"]), including the ServerName.
(Almost)
> All of our MTS components are designed using a custom interface using the
> IMPLEMENTS keyword. The DLL's that gets this error have a reference to
the
> Interface DLL, but not actual MTS components. They are looking for a
pointer
> to our custom interface on the MTS Component only. The client side DLL's
> never reference a property or method on the MTS components other than the
> interface. This allows you to compile the application without the MTS
DLL's
> registered on your machine. I also expected it to allow me to run the
> application without the MTS DLL's registered on the client machine. I am
> correct ?
>
> --
> --
> Thanks,
> David Satz
> Principal Software Engineer
> Hyperion Solutions
> (using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
> (Please respond to the newsgroup.)
>
>
>
>
>
>

[Paul F]

Have you exported your MTS package and run the generated executable on your
client machine. Running the client exe generated by the export updates your
client machines registry to tell it where to look for any request for "itsBSCountry.CBSCountryWrapper".
This way you can pretend that the MTS components are local, so with the create
object method you don't have to specify the servername, the clients registry
will point it to the correct place.
Is this enough detail ?


"DaveSatz" <davidsatz@yahoo.com> wrote:
>I could be much more precise - here is a simplified example of what we are
>doing
>
>We have an interface class, called iBSWrapper in the itsBSInterfaces DLL.
>For simplicity sake, we'll say that the only method on iBSWrapper is
>Pubic Function GetData() AS ADODB.RecordSet
>End Function
>
>itsBSInterfaces DLL is registered on the client machine and on the MTS
>Server (outside of MTS)
>
>We then have a VB Component running under MTS that IMPLEMENTS
>itsBSInterfaces.iBSWrapper as has code the return a recordset in the
>GetData method.
>
>We have DLL's registered on the client machine like this (m_strAppServer
is
>passed in to the DLL from the EXE. m_strAppServer contains the name of
the
>MTS server:
>
>Private m_iBSWrapper As itsBSInterfaces.IBSWrapper
>
>Private Sub CreateMTSWrapper()
>
>On Error GoTo ERROR_LABEL
> Const strWRAPPER As String = "itsBSCountry.CBSCountryWrapper"
>
> If Not m_iBSWrapper Is Nothing Then Exit Sub
>
> If Len(Trim(m_strAppServer)) = 0 Then
> ' for development against local DLLs
> Set m_iBSWrapper = CreateObject(strWRAPPER)
> Else
> ' run under MTS
> Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer)
> End If
> Exit Sub
>
>ERROR_LABEL:
> If Err.Source <> App.EXEName Then
> 'source was deliberately set by this proc or a proc called here,
so
>pass it back as-is
> Err.Raise Err.Number, Err.Source, Err.Description
> Else
> 'vb just raised this error here
> Err.Raise Err.Number, TypeName(Me), Err.Description
> End If
>
>End Sub
>
>I did not register any of the DLL's or typelib's for the DLL's running
>under MTS on the client machine.
>
>The Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer) is what
is
>failing with the "class ..." error message.
>
>
>
>--
>--
>Thanks,
>David Satz
>Principal Software Engineer
>Hyperion Solutions
>(using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
>(Please respond to the newsgroup.)
>
>
>DaveSatz <davidsatz@yahoo.com> wrote in message
>news:39109cb6@news.devx.com...
>> I get this error when I try to use Set objectvariable =
>> CreateObject("progID", ["servername"]), including the ServerName.
>(Almost)
>> All of our MTS components are designed using a custom interface using
the
>> IMPLEMENTS keyword. The DLL's that gets this error have a reference to
>the
>> Interface DLL, but not actual MTS components. They are looking for a
>pointer
>> to our custom interface on the MTS Component only. The client side DLL's
>> never reference a property or method on the MTS components other than
the
>> interface. This allows you to compile the application without the MTS
>DLL's
>> registered on your machine. I also expected it to allow me to run the
>> application without the MTS DLL's registered on the client machine. I
am
>> correct ?
>>
>> --
>> --
>> Thanks,
>> David Satz
>> Principal Software Engineer
>> Hyperion Solutions
>> (using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
>> (Please respond to the newsgroup.)
>>
>>
>>
>>
>>
>>
>
>

[DaveSatz]

I now realize that is what I need to do thanks.

--
--
Thanks,
David Satz
Principal Software Engineer
Hyperion Solutions
(using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
(Please respond to the newsgroup.)


Paul F <pfarnan@informationmosaic.com> wrote in message
news:3912eebc$1@news.devx.com...
>
> Have you exported your MTS package and run the generated executable on
your
> client machine. Running the client exe generated by the export updates
your
> client machines registry to tell it where to look for any request for
"itsBSCountry.CBSCountryWrapper".
> This way you can pretend that the MTS components are local, so with the
create
> object method you don't have to specify the servername, the clients
registry
> will point it to the correct place.
> Is this enough detail ?
>
>
> "DaveSatz" <davidsatz@yahoo.com> wrote:
> >I could be much more precise - here is a simplified example of what we
are
> >doing
> >
> >We have an interface class, called iBSWrapper in the itsBSInterfaces DLL.
> >For simplicity sake, we'll say that the only method on iBSWrapper is
> >Pubic Function GetData() AS ADODB.RecordSet
> >End Function
> >
> >itsBSInterfaces DLL is registered on the client machine and on the MTS
> >Server (outside of MTS)
> >
> >We then have a VB Component running under MTS that IMPLEMENTS
> >itsBSInterfaces.iBSWrapper as has code the return a recordset in the
> >GetData method.
> >
> >We have DLL's registered on the client machine like this (m_strAppServer
> is
> >passed in to the DLL from the EXE. m_strAppServer contains the name of
> the
> >MTS server:
> >
> >Private m_iBSWrapper As itsBSInterfaces.IBSWrapper
> >
> >Private Sub CreateMTSWrapper()
> >
> >On Error GoTo ERROR_LABEL
> > Const strWRAPPER As String = "itsBSCountry.CBSCountryWrapper"
> >
> > If Not m_iBSWrapper Is Nothing Then Exit Sub
> >
> > If Len(Trim(m_strAppServer)) = 0 Then
> > ' for development against local DLLs
> > Set m_iBSWrapper = CreateObject(strWRAPPER)
> > Else
> > ' run under MTS
> > Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer)
> > End If
> > Exit Sub
> >
> >ERROR_LABEL:
> > If Err.Source <> App.EXEName Then
> > 'source was deliberately set by this proc or a proc called here,
> so
> >pass it back as-is
> > Err.Raise Err.Number, Err.Source, Err.Description
> > Else
> > 'vb just raised this error here
> > Err.Raise Err.Number, TypeName(Me), Err.Description
> > End If
> >
> >End Sub
> >
> >I did not register any of the DLL's or typelib's for the DLL's running
> >under MTS on the client machine.
> >
> >The Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer) is what
> is
> >failing with the "class ..." error message.
> >
> >
> >
> >--
> >--
> >Thanks,
> >David Satz
> >Principal Software Engineer
> >Hyperion Solutions
> >(using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
> >(Please respond to the newsgroup.)
> >
> >
> >DaveSatz <davidsatz@yahoo.com> wrote in message
> >news:39109cb6@news.devx.com...
> >> I get this error when I try to use Set objectvariable =
> >> CreateObject("progID", ["servername"]), including the ServerName.
> >(Almost)
> >> All of our MTS components are designed using a custom interface using
> the
> >> IMPLEMENTS keyword. The DLL's that gets this error have a reference to
> >the
> >> Interface DLL, but not actual MTS components. They are looking for a
> >pointer
> >> to our custom interface on the MTS Component only. The client side
DLL's
> >> never reference a property or method on the MTS components other than
> the
> >> interface. This allows you to compile the application without the MTS
> >DLL's
> >> registered on your machine. I also expected it to allow me to run the
> >> application without the MTS DLL's registered on the client machine. I
> am
> >> correct ?
> >>
> >> --
> >> --
> >> Thanks,
> >> David Satz
> >> Principal Software Engineer
> >> Hyperion Solutions
> >> (using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
> >> (Please respond to the newsgroup.)
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>

[ranga raghunathan]

paul
..to continue on server.createobject issue but on a little different track
.. do you know how to implement component load balancing .. if the objects
are installed in server1 but say server 1 crashes, how do the clients know
to instantiate objects in server2.. i thought the appcenter server that is
supposed to be released this year, (win2k series) is supposed to have this
clbs feature.. but in the meantime, was wondering if you have any experience
with dynamically specifying the server..

thanks
ranga
"Paul F" <pfarnan@informationmosaic.com> wrote:
>
>Have you exported your MTS package and run the generated executable on your
>client machine. Running the client exe generated by the export updates your
>client machines registry to tell it where to look for any request for "itsBSCountry.CBSCountryWrapper".
>This way you can pretend that the MTS components are local, so with the
create
>object method you don't have to specify the servername, the clients registry
>will point it to the correct place.
>Is this enough detail ?
>
>
>"DaveSatz" <davidsatz@yahoo.com> wrote:
>>I could be much more precise - here is a simplified example of what we
are
>>doing
>>
>>We have an interface class, called iBSWrapper in the itsBSInterfaces DLL.
>>For simplicity sake, we'll say that the only method on iBSWrapper is
>>Pubic Function GetData() AS ADODB.RecordSet
>>End Function
>>
>>itsBSInterfaces DLL is registered on the client machine and on the MTS
>>Server (outside of MTS)
>>
>>We then have a VB Component running under MTS that IMPLEMENTS
>>itsBSInterfaces.iBSWrapper as has code the return a recordset in the
>>GetData method.
>>
>>We have DLL's registered on the client machine like this (m_strAppServer
>is
>>passed in to the DLL from the EXE. m_strAppServer contains the name of
>the
>>MTS server:
>>
>>Private m_iBSWrapper As itsBSInterfaces.IBSWrapper
>>
>>Private Sub CreateMTSWrapper()
>>
>>On Error GoTo ERROR_LABEL
>> Const strWRAPPER As String = "itsBSCountry.CBSCountryWrapper"
>>
>> If Not m_iBSWrapper Is Nothing Then Exit Sub
>>
>> If Len(Trim(m_strAppServer)) = 0 Then
>> ' for development against local DLLs
>> Set m_iBSWrapper = CreateObject(strWRAPPER)
>> Else
>> ' run under MTS
>> Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer)
>> End If
>> Exit Sub
>>
>>ERROR_LABEL:
>> If Err.Source <> App.EXEName Then
>> 'source was deliberately set by this proc or a proc called here,
>so
>>pass it back as-is
>> Err.Raise Err.Number, Err.Source, Err.Description
>> Else
>> 'vb just raised this error here
>> Err.Raise Err.Number, TypeName(Me), Err.Description
>> End If
>>
>>End Sub
>>
>>I did not register any of the DLL's or typelib's for the DLL's running
>>under MTS on the client machine.
>>
>>The Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer) is what
>is
>>failing with the "class ..." error message.
>>
>>
>>
>>--
>>--
>>Thanks,
>>David Satz
>>Principal Software Engineer
>>Hyperion Solutions
>>(using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
>>(Please respond to the newsgroup.)
>>
>>
>>DaveSatz <davidsatz@yahoo.com> wrote in message
>>news:39109cb6@news.devx.com...
>>> I get this error when I try to use Set objectvariable =
>>> CreateObject("progID", ["servername"]), including the ServerName.
>>(Almost)
>>> All of our MTS components are designed using a custom interface using
>the
>>> IMPLEMENTS keyword. The DLL's that gets this error have a reference
to
>>the
>>> Interface DLL, but not actual MTS components. They are looking for a
>>pointer
>>> to our custom interface on the MTS Component only. The client side DLL's
>>> never reference a property or method on the MTS components other than
>the
>>> interface. This allows you to compile the application without the MTS
>>DLL's
>>> registered on your machine. I also expected it to allow me to run the
>>> application without the MTS DLL's registered on the client machine.
I
>am
>>> correct ?
>>>
>>> --
>>> --
>>> Thanks,
>>> David Satz
>>> Principal Software Engineer
>>> Hyperion Solutions
>>> (using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
>>> (Please respond to the newsgroup.)
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

[Paul F]

Don't think this issue is component load balancing in the strict sense - more
like some sort of failover strategy. I have not worked with this issue regarding
MTS only at an academic level. I know its not possible to specify multiple
servers with the current version of MTS (not too sure of W2K) as the current
remote architecture that MTS uses requires client executables to be generated
on the server machine therefore we would have two client executables, thus
one would overwrite the registry entry of the other. However there is some
way around this.
If this is totally essential you could do the following.
Have your client machine channels its DCOM reqiurements through the one component
- like a proxy component(recommended in COM programming). This proxy component
then looks after the generation of server side components. Now, if you plan
to use two potential servers you would have to name you server components
differently on each of the servers.
Server-side class called "CustomerServer". This resides in a DLL DLLCustServer.
So in a single server environment you would have
CreateObject("DLLCustServer.CustomerServer").
In a multi-server environment however the DLL on one server would be named
differently to the DLL on ther other server. eg. "DLLCustServer1" and "DLLCustServer2".
This allows two different GUIDs to be generated for each component when the
export exe's are generated even though they do exactly the same work, so
they can be safely registered on the same client machine without overwriting
each other.
Now in yur client proxy component you can catch object creation errors and
then try the alternative.
eg.

On Error Goto CreateError
Set myObj = CreateObject("DLLCustServer1.CustomerServer")
if myObj is nothing then
Set myObj = CreateObject("DLLCustServer2.CustomerServer")
end if

CreateError:
Resume Next

Long winded I know but let me know if there is something better/more efficient
out there in case I ever come across the problem.

P.

"ranga raghunathan" <ranga1@msn.com> wrote:
>
>paul
>..to continue on server.createobject issue but on a little different track
>.. do you know how to implement component load balancing .. if the objects
>are installed in server1 but say server 1 crashes, how do the clients know
>to instantiate objects in server2.. i thought the appcenter server that
is
>supposed to be released this year, (win2k series) is supposed to have this
>clbs feature.. but in the meantime, was wondering if you have any experience
>with dynamically specifying the server..
>
>thanks
>ranga
>"Paul F" <pfarnan@informationmosaic.com> wrote:
>>
>>Have you exported your MTS package and run the generated executable on
your
>>client machine. Running the client exe generated by the export updates
your
>>client machines registry to tell it where to look for any request for "itsBSCountry.CBSCountryWrapper".
>>This way you can pretend that the MTS components are local, so with the
>create
>>object method you don't have to specify the servername, the clients registry
>>will point it to the correct place.
>>Is this enough detail ?
>>
>>
>>"DaveSatz" <davidsatz@yahoo.com> wrote:
>>>I could be much more precise - here is a simplified example of what we
>are
>>>doing
>>>
>>>We have an interface class, called iBSWrapper in the itsBSInterfaces DLL.
>>>For simplicity sake, we'll say that the only method on iBSWrapper is
>>>Pubic Function GetData() AS ADODB.RecordSet
>>>End Function
>>>
>>>itsBSInterfaces DLL is registered on the client machine and on the MTS
>>>Server (outside of MTS)
>>>
>>>We then have a VB Component running under MTS that IMPLEMENTS
>>>itsBSInterfaces.iBSWrapper as has code the return a recordset in the
>>>GetData method.
>>>
>>>We have DLL's registered on the client machine like this (m_strAppServer
>>is
>>>passed in to the DLL from the EXE. m_strAppServer contains the name of
>>the
>>>MTS server:
>>>
>>>Private m_iBSWrapper As itsBSInterfaces.IBSWrapper
>>>
>>>Private Sub CreateMTSWrapper()
>>>
>>>On Error GoTo ERROR_LABEL
>>> Const strWRAPPER As String = "itsBSCountry.CBSCountryWrapper"
>>>
>>> If Not m_iBSWrapper Is Nothing Then Exit Sub
>>>
>>> If Len(Trim(m_strAppServer)) = 0 Then
>>> ' for development against local DLLs
>>> Set m_iBSWrapper = CreateObject(strWRAPPER)
>>> Else
>>> ' run under MTS
>>> Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer)
>>> End If
>>> Exit Sub
>>>
>>>ERROR_LABEL:
>>> If Err.Source <> App.EXEName Then
>>> 'source was deliberately set by this proc or a proc called here,
>>so
>>>pass it back as-is
>>> Err.Raise Err.Number, Err.Source, Err.Description
>>> Else
>>> 'vb just raised this error here
>>> Err.Raise Err.Number, TypeName(Me), Err.Description
>>> End If
>>>
>>>End Sub
>>>
>>>I did not register any of the DLL's or typelib's for the DLL's running
>>>under MTS on the client machine.
>>>
>>>The Set m_iBSWrapper = CreateObject(strWRAPPER, m_strAppServer) is what
>>is
>>>failing with the "class ..." error message.
>>>
>>>
>>>
>>>--
>>>--
>>>Thanks,
>>>David Satz
>>>Principal Software Engineer
>>>Hyperion Solutions
>>>(using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
>>>(Please respond to the newsgroup.)
>>>
>>>
>>>DaveSatz <davidsatz@yahoo.com> wrote in message
>>>news:39109cb6@news.devx.com...
>>>> I get this error when I try to use Set objectvariable =
>>>> CreateObject("progID", ["servername"]), including the ServerName.
>>>(Almost)
>>>> All of our MTS components are designed using a custom interface using
>>the
>>>> IMPLEMENTS keyword. The DLL's that gets this error have a reference
>to
>>>the
>>>> Interface DLL, but not actual MTS components. They are looking for a
>>>pointer
>>>> to our custom interface on the MTS Component only. The client side
DLL's
>>>> never reference a property or method on the MTS components other than
>>the
>>>> interface. This allows you to compile the application without the MTS
>>>DLL's
>>>> registered on your machine. I also expected it to allow me to run the
>>>> application without the MTS DLL's registered on the client machine.

>I
>>am
>>>> correct ?
>>>>
>>>> --
>>>> --
>>>> Thanks,
>>>> David Satz
>>>> Principal Software Engineer
>>>> Hyperion Solutions
>>>> (using VB6 SP3/MTS/SQL Server 6.5 SP5a./MDAC 2.1.2.4202.3)
>>>> (Please respond to the newsgroup.)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>