dlltool: unrecognized option `--input-def'

    --def <deffile>        Name input .def file
[download]

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.

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.

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

> 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]

Curious, can you please post a sanitized tnsnames.ora?

Update: https://www.dbasolved.com/2012/12/ora-25401-cannot-continue-fetches/. Does cranking up tracing turn up anything useful?

I had found that same first link as well, but when I compared my tnsnames.ora file to it it's identical to the "after" version (obviously with the correct host, port, and service name for my employer's Oracle DB). Very simple, it's actually what my Oracle Database Admins have posted to use as the default on their intranet page at my employer for these things. That same tnsnames.ora file is what I loaded in to my SQL Developer install to get it working, and there I can run the same query that my Perl script chokes on.

DWAPRD =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = XXX)(PORT = XXX))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = XXX)
    )
  )
[download]

I'm only just learning this stuff, all my previous database access has been heavily curated through various approved environments that handle all the connection stuff behind the scenes. The only reason I want direct access is so that after 2-3 years of dumping tab delimited and/or Excel files via those approved environments and reading them in to my scripts, I can skip all that manual overhead. Sometimes it's horribly tedious because I have to dump multiple files from multiple sources, save them in different formats, then get them in to a directory with my Perl scripts to do what I need... man, it would be so nice to skip all that with a direct pipeline to the various data sources via Perl. So here I am, struggling. :-/

I'll see if I can figure anything out with the tracing suggestion.

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

my $results = $sth->fetchall_arrayref( {} );
foreach my $row (@$results) {
    print $row->{'TABLE_NUMBER'}, " ", $row->{'LOV_INTEGER_KEY'}, " ",
      $row->{'LOV_DISPLAY_KEY'}, " ", $row->{'NOTE'}, "\n";
}
[download]

In this case, it just seems to hang forever once it reaches this point in the execution. The script runs an earlier query just fine. I'm thinking it's something funky in the data that something in my Perl specific data pipeline is choking on. There are some funky things in the data of these particular tables, especially the "NOTE" data which I only read to strip a country name from the front of and throw away a bunch of junk on the end. Example of what I mean:

47 138 0 1O                                       ARMENIA             
+          AMFFFTTFTFXXXX XXXXX XX   O      X X    TTFFFARM
48 138 0 1T                                       ARUBA               
+          AWFFFOFTTTXX X XXXXX X X  O    X        TTFTTABW
49 138 0 1Y                                       AUSTRALIA           
+          AUFFFTFTTTX    X XX       OXXXXX       XFFFFFAUS
50 138 0 23                                       AUSTRIA             
+          ATFFFTTTTTX    X XX  X X  OXXXXX       XFFFTTAUT
[download]

Sometimes I get in over my head on stuff like this, especially when I'm largely ignorant about how to properly configure my tools to do what I think I might need or want.

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

Try removing columns from the query to see if one of them is causing the error. What are the data types of the columns?