🚀 go-pugleaf

Using OLE Viewer helps to gain visibility to a DCOM server where simply
registering it did not. The key is, as you suggested in the MER System, to
link the DLLHOST.EXE as a surrogate using OLE Viewer.

http://community.borland.com/article/0,1410,26048,00.html
http://www.microsoft.com/com/resources/oleview.asp

The problems we've had in the past are basically described here. We will
pursue the project with this in mind.


"mpowell" <mike.powell@transcore.com> wrote in message
news:97od9h$ccv4@bornews.inprise.com...
>
> There aren't many steps WRT the socket server problems. We simply run it,
> run the client application, connect, perform some database activity,
> disconnect, close the client application, then try to reopen and reconnect
> the client application. At this point the client application hangs. We did
> everything "by the book" in terms of connecting and disconnecting, yet
there
> appears to be some resources in the socket server that are not playing
well.
> I've read at least half a dozen other posts in this (and other Borland IB
> related groups) to this effect. We are running Windows 2000 and Builder 5
> Enterprise. Borland claims to have tested its software with Windows 2000,
> but apparently missed this one.
>
> We are testing on the development machine. So, yes, the MIDAS.DLL resource
> has been deployed and registered. In a production environment obviously we
> would have installed and registered this file as well. The server too
exists
> and has been registered on the server via the /REGSERVER switch or by
> running it. In a production environment it would be ill advised to expect
> that running the server is acceptable when installing it for the first
time.
>
> I will scour the MER Systems archive as you suggested. We're really at a
> loss as to how to proceed. It seems our difficulty in registering servers
> and connecting has only gotten worse with Windows 2000 and BCB5.
>
>
> "Dan Miser (TeamB)" <dmiser@wi.rr.com> wrote in message
> news:97ndl7$3o710@bornews.inprise.com...
> > As I mentioned in my last post to you about this subject, a DLL will not
> > show up in DCOMCNFG. This is the way MS designed their software. Try
> > searching www.mers.com for "surrogate" for some more information.
> Searching
> > "surrogate miser" will get you even more targetted information.
> >
> > I don't know of any bugs in SCKTSRVR that prevent the server from
cleaning
> > up any resources. If you have explicit steps you want to post, I'll take
a
> > look.
> >
> > As for the "Class not registered" error, did you remember to deploy and
> > register MIDAS.DLL (via regsvr32)?
> > --
> > Dan Miser
> > http://www.distribucon.com
> >
> > "mpowell" <mike.powell@transcore.com> wrote in message
> > news:97mjpg$fob4@bornews.inprise.com...
> > >
> > > We are experiencing great difficulty connecting under Windows 2000.
Let
> me
> > > explain what it is we're doing. As stated earlier we are using Windows
> > 2000
> > > and C++Builder 5 Enterprise.
> > >
> > > We first tried to build a MIDAS DLL server followed by a MIDAS EXE
> server.
> > >
> > > In the DLL case, we had problems registering properly. After
registering
> > we
> > > could not see the server using DCOM Config. We also cannot seem to
> connect
> > > to the server using DCOM to another (albeit W2K Professional) machine.
> > Using
> > > TSocketConnection, while this worked, would not clean up after itself
so
> > we
> > > have decided it will not do in its current bug filled state.
> > >
> > > In the EXE case we seem to register the server just fine both by
running
> > the
> > > application itself and by using the command line argument /REGSERVER.
> The
> > > application does appear using DCOM Config. However, all attempts to
> > connect
> > > either remotely or locally have failed in "class not registered".
> >
> >
> >
>
>