🚀 go-pugleaf

Ok, now we're so close to connecting to a DLL server it hurts. The
TDCOMConnection seems to try to resolve connecting to the remote server, but
we get the EOleSysError error "Server execution failed". So I suspect we're
timing out somewhere in between. Now, I seem to remember there being some
issues with security and whether the server process runs as the interactive
user. How precisely do we need to configure a DLL server to run using OLE
Viewer or perhaps DCOM Config?


"mpowell" <mike.powell@transcore.com> wrote in message
news:97ohoi$a055@bornews.inprise.com...
>
> 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".
> > >
> > >
> > >
> >
> >
>
>