🚀 go-pugleaf

Ok, now we've got the client (located on Windows 2000 Professional)
apparently connecting to Windows NT Server. However, when we attempt to
invoke a function on the dispatch interface we receive DISP_E_EXCEPTION. It
doesn't appear as though the function is even being executed on the servers
end. Or, at least, we know the function isn't having the intended effect on
the backend database.

The current configuration we have is:

Windows NT Server
IB 6.01 (with security patch)
Application database
ActiveX DLL server (registered and configured using OLE Viewer)

Windows 2000 Pro Workstation
Client application
Communications to server via TDCOMConnection
Dispatch to server's interface using TDCOMConnection->AppServer

Any ideas what we might be doing wrong?


"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".
> > >
> > >
> > >
> >
> >
>
>