GREAT! I'm glad to hear you got this mystery solved. Microsoft calls executables "modules". This could mean any DLL or EXE, not just a COM server. In fact, there is a Win32 API function named "GetModuleFileName" that can return the path to the "module" from which it is called. This of course doesn't help you now, but at least it might help clarify the "module not found" message.
-Clift > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bob > Kline > Sent: Friday, June 14, 2002 8:14 AM > To: Patricia J. Hawkins > Subject: Re: pythoncom not loaded > > > On 13 Jun 2002, Patricia J. Hawkins wrote: > > > >>>>> "BK" == Bob Kline <[EMAIL PROTECTED]> writes: > > > > BK> No, I get the message "No module named pythoncom" when I do > that. The > > BK> original problem has "The specified module could not be > found." (This > > BK> was raised by an attempt to invoke pythoncom.CoCreateInstance()). > > > > OK, that's interesting, it's a different error, which makes the > > source of the original error intriguing. > > > > Hmmm. Looking at dynamic.py, I see that the error is coming from > > the except clause in an exception handler. I'd put a print > > statement -- printing out the value of IDispatch, what the heck, and > > maybe clsctx -- before and after line 70, and also right after the > > except statement. Or step through it in a debugger, but printing is > > cheap and easy. > > Hey, you're good at this! > > Inspired by your suggestions, I did some more digging around in the > registry, but this time looking for problems with COM instead of Python. > In spite of what I assumed when I saw a Python exception telling me it > couldn't find a module, this wasn't referring to a Python module at all. > > As usual, once you solve the mystery, the clues look much more obvious. > For example, if I had paid more attention, I would have realized the > implications of the name of the type of exception raised ("com_error"). > It's very unfortunate that Microsoft chose "module" to describe what it > couldn't find instead of coming out and saying it couldn't find a COM > server. It would have been nice, too, if the exception had given the > name of what it couldn't find. Oh, well. > > Sure enough, the InprocServer32 value for the ADODB.Connection key's > CLSID was "H:\Program Files\Common Files\System\ADO\msado15.dll" which > was pointing to a private network directory. After some grilling of the > system administration staff, they admitted that someone had, with > perfectly good intentions I'm sure, come up with the brilliant idea of > setting the environment variable CommonProgramFiles to point to the > user's private home directory on the network in the network logon script > controlled by the domain administrators. It wasn't long before they > realized that this was a mistake and backed it out of the login script, > but it was too late -- the damage had already been done on this machine. > And of course, they didn't tell anyone what they had done. And of > course there aren't any clues from the MDAC installation process that > this environment variable has been silently used to stick all the > software off in a corner of the network where no other users but the one > running the installation can get to it. > > Once I did some surgery on the registry, and got the files into the > local machine's file system, the problem disappeared. > > Thanks again for your excellent sleuthing tips! > > -- > Bob Kline _______________________________________________ ActivePython mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs Other options: http://listserv.ActiveState.com/mailman/listinfo/ActivePython
