If you have an emergency problem, and corporate IT policies are preventing you from getting your job done, you need to escalate through your management, and get it on record. I'm not recommending starting a fight over it, but the cost on productivity of stupid policies needs to be made visible, or stupid policies will never go away.

If you can, phrase the problem in dollar terms, since upper management understands money. And don't point fingers. "This policy is preventing me from completing this project. Every day I'm prevented from completing this project is costing you $X" can get more attention than a "those meanies in IT won't let me blah blah blah" whine.

And while you're taking the high road, you might be able to download the .PPM files over MSIE, then trick out PPM to use a local (on the same machine) web server to do the install.

What are your issues with getting PPM to communicate over your HTTP proxies? This is documented in the ActivePerl documentation installed with ActivePerl. Support for HTTP proxies should be rather complete.

I'm afraid the only advice I can offer is to re-install stuff correctly. The fact that you said this is a hacked install makes me reasonably confident this has something to do with your problem.

I have ActivePerl on my PC on a corporate Intranet that allows Internet access only via authenticated HTTP proxies, and I've used PPM without incident.

The proxy is authenticated, but the authentication is a "secret." IE: The name of the proxy server, the UID used, and the password are all unknown, and corporate policy is, they won't let us know any of them. So "direct" HTTP is impossible.

By "hacked install," I mean that the ActivePerl MSI is installed just fine, but the Tk, DBI, and DBD::ODBC drivers were simply "copied in", e.g. from ".../blib/lib/*.pm" to ".../perl/lib/*.pm", directory tree intact.

The access violation seems to say to me that one of (DBI.DLL?, PERL.EXE, PERLCRT.DLL) is mismatching the versions of the others; but the DBI.tar.gz was just pulled today from ActiveState.Com/packages/x86, so I don't know how that's possible...

I would agree that your assumption about mismatched binary versions is the likely culprit, but I don't know that I can recommend an easy way to fix it without doing a proper install.

You may want to try copying the entire Perl tree from one system to another. I don't know if ActivePerl would have a problem with that.

Can you download the binary versions of these modules directly from ActiveState's web site? Do you have a support agreement with them that you can use to get an alternate installation path for these?

(And off-topic for a second, how does your HTTP proxy work with IE if you don't know the username/password of the proxy? Don't you have to type it in? Or is it a special version of IE that hides this information and sends it secretly in the background without your knowledge? I've just never heard of a configuration like this before. Maybe your technical staff there can help you with finding another way of getting this application through your HTTP proxy? If they're forbidding the traffic, then they need to be prepared to have you incur these additional expenses in getting stuff like this to work... Just my 2 cents.)

Doh!

The download at /packages on ActiveState's site is broken, apparently, but http://www.activestate.com/PPMPackages/zips/6xx-builds-only/ is good. It would help if it were linked on their website, but Google managed to locate it for me (on the 20-some-aught page of results, but found, nonetheless)

Thanks, all!