>I Have an application using Microsoft's Date Time Picker that runs off of our Server. We have just moved our NT server over to windows 2000 server. This program was running fine on the NT server. But now that it is on the 2000 server when the 95 and NT clients access the form with the dtPicker they get an OLE class Not registered error. When the application was running on the NT server all I had to do was register the control on the server and since the application is actually running off of the server the clients did not need the class registered on the clients side. Any suggestions or known work arounds other than registering the ocx on the clients. Note: The 98 clients work fine. I have registered the mscomct2.ocx on the 2k server and the application runs fine on the server. Does anybody know why this could be happening?
The reason it stopped working is in all probability due to the change in location due to the change in the server. You've run into one of the many potential problems of using a COM/ActiveX component whose location is not fixed relative to the target machine running it; any change in the pathing results in a failure of Windows to resolve the location when the CLSID or ProgID is used to request the component or information regarding that component.
Lots of things may have happened. let's assume for a moment that you previously registered the control on a system using a mapped drive letter to specify its location. In this case, even changing the drive letter mapping will probably cause the control to become inaccessible. If the control were previously found at "G:\MyApp\MyControls", where G: was mapped to \\MyServer\MyShare, changing the mapping for G: to \\MyServer\AnotherShare breaks the link in the registry, because the control can't be found relative to the new definition for drive G:, and this applies to changing the server name, or simply to not mapping the G: drive at all. Because G: is not a fixed location, changes to the mapping break the connection between the registry and the control.
You might use the UNC for registration; now, instead of a path relative to the mapped letter G:, your control is now said to be located at "\\MyServer\MyShare\MyApp\MyControls" - an unchanging path, so that even if G: hasn't been mapped, or is mapped to some other path, the control can still be found using the UNC. SO much for Ed remapping the G: drive on me, or so you think...
Down the stairs comes Ed, grinning about the nifty new server they've moved your app to. It's on the new 8 processor Pentium VII machine named "EdServer", and the guys up in IT moved everything over to the new box, and even took care of your login script so that G: is mapped to the new server in the same relative path. In fact, in two minutes, they're gonna shut off the old server "MyServer" and let all of you use "EdServer", so you can get your work done that much faster! Unfortunately, all those registry entries that pointed to things on "\\MyServer" are now busted to hell and gone, and you'll spend the next two weeks going from machine to machine re-registering everything that used to be on the "\\MyServer" machine. You just can't win...
If you put the controls on the local system, these things don't happen. When new versions of controls are released or needed, you need to push them out to each client machine, but, then, you had to register them anyway, now you have to copy and register. In addition, if running Win2K or XP, both of which support something called side-by-side registration and control versioning, it possible for several apps, each of which uses its own version of a particular control, to associate the right control version with the right app.
IOW, install and register components locally if you expect to run them locally...
