http://qs1969.pair.com?node_id=101185

jjhorner has asked for the wisdom of the Perl Monks concerning the following question:

I'm having DBD::Oracle permission issues on an NT 4.0 Server running IIS:

I have a script: 

print "Content-Type: text/html\n\n"; 

print "<HTML>\n"; print "<HEAD>\n"; 
print "<TITLE>test_db</TITLE>\n"; 
print "</HEAD>\n"; 
print "<BODY>\n"; 
print "<H4>Hello World</H4>\n"; 
use DBI;
use DBD::Oracle;
print "<p>DBI and DBD::Oracle loaded.</p>\n";
print "</BODY>\n"; 
print "</HTML>\n";

[download]

I get the following error when I try to allow anonymous access to this script, I get: 

CGI Error

The specified CGI application misbehaved by not returning a complete s
+et of HTTP headers. The headers it did return are:

Can't load 'C:/Perl/site/lib/auto/DBD/Oracle/Oracle.dll' for module DB
+D::Oracle: load_file:Access is denied at C:/Perl/lib/DynaLoader.pm li
+ne 200.
 at "PATH"\test_perl.pl line 9
Compilation failed in require at "PATH"\test_perl.pl line 9.
BEGIN failed--compilation aborted at "PATH"\test_perl.pl line 9.

[download]

Where PATH is actual system path (sanitized).

When I force logins, everything works fine. I have changed permissions on my c:\Perl, c:\orant, and c:\winnt directories to be Everyone Full Control (it won't stay this way once we get this fixed.)

My only thought is that something, somewhere doesn't allow access to our anonymous user account, but I don't know where. I've checked all of the known places.

Any ideas? 

J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org/

Edit: chipmunk 2001-08-02

Replies are listed 'Best First'.
(Ovid) Re: DBD::Oracle issues
by Ovid (Cardinal) on Jul 31, 2001 at 19:23 UTC

    This may be a complete Red Herring, but why do you need to load DBD::Oracle? The DBI module handles that for you. I've done a lot of database programming with DBI and I've never had to load a DBD. Have you simply tried to use DBI and let it handle the DBD for you?

    Cheers,
    Ovid

    Vote for paco!

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]

      In the production script, we just do a DBI connect, but it is failing also. Since we can get the same error just by calling DBD::Oracle, I just sent this code to show the error.

      I hope this helps. 

      J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org/
[reply]

        You may not have a permissions problem, though it certainly appears to be one. Here's the comments in Dynaloader immediately prior to line 200:

            # Many dynamic extension loading problems will appear to come from
    # this section of code: XYZ failed at line 123 of DynaLoader.pm.
    # Often these errors are actually occurring in the initialisation
    # C code of the extension XS file. Perl reports the error as being
    # in this perl code simply because this was the last perl code
    # it executed.

        [download]

        How did you install DBI and DBD::Oracle? If you compiled DBD::Oracle yourself, perhaps there was an error? Can you successfully load other DBDs?

        Side note: I think your Perl code is not doing exactly what you think it's doing. Your use statements are embedded in the HTML and you print statements saying that "such and such modules were loaded". However, use happens at compile time, not run-time, so your statements regarding when they were loaded are misleading. That's also why you're getting the incorrect headers: The error messages are output prior to "Content-type: text/html\n\n" being printed.

        Cheers,
        Ovid

        Vote for paco!

        Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
[d/l]
Re: DBD::Oracle issues
by LD2 (Curate) on Jul 31, 2001 at 19:43 UTC
    You may be interested at this. They mention that installing DBD-Oracle8, instead of DBD-Oracle solved the problem. Also check on the version number - 1.06 solves a few problems that were in 1.03. Hope this helps a bit.
[reply]

      I appreciate your help.

      I tried this, and still no love.

      This script and any other script we have relating to this problem work as long as we don't try to authenticate to IIS using the anonymous user. If we are forced to authenticate, via dialog, it works. Since my partner and I are administrators on all of our web servers, we have no problems. Others that are forced to authenticate with a domain uid have no problems.

      Thanks, though, for your help. You have clued me in to something I need to look our for in the future. 

      J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org/
[reply]

Back to Seekers of Perl Wisdom