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
mailto:[EMAIL PROTECTED]
http://www.rksystems.com
_______________________________________________
ActivePython mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/ActivePython
