Now this was *really* weird. I fixed the DBD::mysql problem by adding '/usr/lib64/perl5/vendor_perl’ to my ‘use’ statement in startup.pl, EVEN THOUGH it’s already in @INC, and DBD::mysql lives in /usr/local/lib64/perl5/DBD
DBI lives in that directory, but other scripts using DBI and DBD::Oracle were working as expected. Now my test script shows '/usr/lib64/perl5/vendor_perl’ twice in @INC: @INC /home/allwebfiles/perl/LocalModules /usr/lib64/perl5 /usr/share/perl5 /usr/local/lib64/perl5 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/vendor_perl/Bundle /usr/local/share/perl5 /usr/share/perl5/vendor_perl /etc/httpd So possibly an order in @INC thing? The above list is an un-sorted traversal of @INC, but since there’s only one place that you can find DBD::mysql I don’t understand how that could be an issue. On Jun 3, 2020, at 12:54 PM, Bill Hess <bh...@techrg.com<mailto:bh...@techrg.com>> wrote: Do you set PERL5LIB in the environment who is running Apache? If not - then maybe try to set the path where you have DBD::MySQL installed Your line 'use lib ....' should handle this but we have seen issues in the past when setting it on the fly like this - so using PERL5LIB has solved issues for us vs using 'use lib ...' -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs
