o, I would replace --input-def by --def on line 330 of Makefile.PL and rerun the installation.

I would not. I would fix %PATH% to exclude some 50 year old version of dlltool. the dlltool.exe that comes with strawberryperl accepts --input-def option.

How can I update my system PATH to do this? I already have "C:\Strawberry\perl\bin" at the top. Doesn't that point it there first?

Just another Perl hooker - My clients appreciate that I keep my code clean but my comments dirty.

I already have "C:\Strawberry\perl\bin" at the top.

But is that where dlltool.exe is found? You can use the Windows cmd.exe utility where to see all the locations of a given executable in your PATH -- in the order found; the first one listed will be the one that it runs. On my system, I only have one (with my highly-customized berrybrew wrapper around Strawberry perl):

C:\>where dlltool
C:\usr\local\apps\BERRYBREW\perls\system\c\bin\dlltool.exe
[download]

I believe in a default Strawberry installation, the equivalent would be C:\Strawberry\c\bin. Note in Strawberry's portableshell.bat, they use set PATH=%~dp0perl\site\bin;%~dp0perl\bin;%~dp0c\bin;%PATH% -- they add three directories to the path. So if I were you, I would add set C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\Strawberry\c\bin all before %ORACLE_HOME%\bin.

(note: I do not know if the anonymous monk is looking down the right solution-trail, and whether fixing your PATH will solve your underlying problem. I just wanted to point out how to find out what copy of an executable is first in your PATH , and how to set your PATH so that all the Strawberry executables come before any that might be in the %ORACLE_HOME%\bin)

--
update: clarified the parenthetical

Generally stuff like this is a bit outside my depth, but I'll try to follow along. Apologies if I have to ask you to explain things to me like I'm a five year old.

It's odd, searching for the proper Makefile.PL to edit and going in to "C:\Strawberry\cpan\build" of my install I show 12 different "DBD-Oracle-1.80" directories just progressively numbered all last modified a couple days ago when I was trying to get that module installed and working for me properly.

I tried deleting them all but the original "DBD-Oracle-1.80-0" one and updating the Makefile in it as you suggested, but it didn't seem to help. I also tried deleting them all and reinstalling form CPAN but got the same result.

I did have to mess around with my system PATH variable after installing a suitable version of Oracle Client, I mostly followed afoken's guide here. Currently my system PATH variable has "C:\Strawberry\Perl\bin" at the top followed by "%ORACLE_HOME%\bin". If I recall, one issue I had is that when those were flipped my system kept loading an earlier version of Perl out of the Oracle directory instead of the Strawberry\Perl directory.

> cpan
...
cpan[1]> get DBD::Oracle
...
cpan[2]> look DBD::Oracle
... # Fix the Makefile.PL
> perl Makefile.PL
> make  # or your variant whereof
> make install
> exit
cpan[3]>
[download]

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Awesome, that worked and it installed successfully. Thanks, choroba.

The bad news is that didn't fix my original issue. :-/

I'm still seeing the "fetchrow_hashref" fail... typically it either hangs forever on the same row, or it gets passed that row, hangs for a short time on another culprit row and then gives the error in the title of this thread before successfully running another query on another table and the script finishing...

If it's something in the actual data for those rows that's causing it to fail it's odd that sometimes it fails on the earlier row and sometimes not. I am able to run the same query from a SQL Developer environment without issue.

Just another Perl hooker - My clients appreciate that I keep my code clean but my comments dirty.