🚀 go-pugleaf

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

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

There is no documentation in the Windows help regarding DLLHOST.EXE (at
least none that I can find). Nor does there appear to be any help when I use
/? or -? switches. How is this utility used? I understand that basically we
run this software (somehow) and magically a DLL server appears and its
security may be tweaked. Is there a way to do this programmatically perhaps
so we don't have to tinker with the DLL in any extracurricular sense?


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

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

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

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