Link to home
Start Free TrialLog in
Avatar of rwp9350
rwp9350

asked on

Error During application setup while registering MSRDC20.OCX in VB5.0

When either manually registering all ocx's or even using VB 5.0's setup utility, we are having a problem registering
the RDO 2.0 control (ocx) for the application developed.  In both cases, using the setup program or manually
registering MSRDC20.OCX it will not register on the clients machine.

This is our first attempt at deploying a VB5.0 and SQL server 6.5
application.  Any help would be appreciated.

Avatar of ksleung
ksleung

Does it only happen to the MSRDC20.OCX? How about other controls?
Avatar of rwp9350

ASKER

All other controls seem to register correctly, when using the vb setup disks utility even it had a problem in registering MSRDC20.OCX.  Of course when you try to fire up the application a message box appears to tell you that the RDO control is not correctly registered.
Avatar of rwp9350

ASKER

I have upped the number of points in order to get this solved.
ASKER CERTIFIED SOLUTION
Avatar of Chizl
Chizl
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of rwp9350

ASKER

I believe that Chizl had a good answer, but it doesn't look like it is the problem.  In trying other things yesterday, on the test machine we have, it hasn't had any office 97 product loaded on it yet.  In comparing my machine and another test machine that the VB5 application does work on I noticed in the registry there were several entries for the MSRDC20.OCX in several folders named InProcServer32 where the OCX was registered.  In addition, there was another entry in the Shared software section for the OCX.  

On the test machine that would not register the OCX there was no entries whatsoever.  I then installed Access 8.0 and immediately tried to run my app and it worked!  I then checked that machines registry and the MSRDC20.OCX and MSRDO20.DLL registered correctly.

Bottom line, it appears to me to be a bug with the OCX and DLL in not self-registering themselves as they should by creating the proper registry entries.  Otherwise, the workaround is to have an Office 97 product installed on the client machine until Microsoft corrects the bug.