I am getting the below error message while executing my Perl script.
Below is the error message that I am getting while compiling my scripts.
install_driver(Oracle) failed: Can't load '/xxx/usr/local/lib/perl5/site_perl/5.10.0/sun4-solaris/auto/DBD/Oracle/Oracle.so'
for module DBD::Oracle: ld.so.1: perl: fatal: libclntsh.so.10.1: open failed: No such file or directory at
/xxx/usr/local/lib/perl5/5.10.0/sun4-solaris/DynaLoader.pm line 203.
at (eval 99) line 3
Compilation failed in require at (eval 99) line 3.
Perhaps a required shared library or dll isn't installed where expected
at /xxx/xxxx/xxxx/xxxx/XXXX/CommonOracle.pm line 71
Recently Oracle have been upgraded from 10.2 to 11.0 in my system. Please help me to fix the issue? I am not the administrator of my system. Do i need to change LD_LIBRARRY_PATH? I am using Solaris OS.
You seem to have forgotten to ask a question. Let's assume it's "how can I fix this?"
Communicating with a database requires a number of things to be installed on your system.
You need the client libraries for the database system that you're using. This will be shared object (.so) files that are probably somewhere under /usr/lib.
You will need the Perl Database driver for your database engine (in your case, this is DBD::Oracle). If you install this by building it from scratch (as the cpan or cpanm commands do) then you'll almost certainly also need the development version of the above-mentioned client libraries. If you're installing pre-built binary versions (.rpm or .apt on Linux - I don't know the equivalent for Solaris) then you won't need these.
You will need the Perl DBI library.
It looks to me like DBD::Oracle is installed. And that means that DBI will be installed as well. But DBD::Oracle is having trouble finding the client libraries. This is surprising as they will hae been needed to install DBD::Oracle.
So, I suspect that either the Oracle client libraries are no longer installed or they are installed, but not in the place where DBD::Oracle is looking for them.
How was DBD::Oracle installed? Do you have a log of that installation that you can inspect for errors?
The issue has been resolved. The lib file "libclntsh.so.10.1" was missing in the library path. I have copied the file and the issue was resolved
Related
So I wanted to get started on Ruby on Rails because it sounds like fun but as I reached part 3.1 over here I ran into some problems.
First I just attempted "sqlite3 --version" in the "ruby cmd" and it came up with: "'sqlite3' is not recognized as an internal or external command, operable program or batch file." So I attempted to just install the sqlite ruby gem and it did that just fine but as I typed "sqlite3 --version", same story. So I just figured you needed to install the thing your self.
So after I downloaded the "Precompiled Binaries for Windows" (64-bit DLL (x64) for SQLite version 3.11.1.) over here I moved the .dll and .def files to my system32 folder, launched CMD as admin and typed regsvr32 sqlite3.dll I get this error message: "The module "C:\WINDOWS\System32\sqlite3.dll" was loaded but the entry-point DIIRegisterServer was not found. Make sure that "C:\WINDOWS\System32\sqlite3.dll" is a valid DLL or OCX file and then try again.
I did a lot of googleing and talked with microsoft support and nothing helped. So im hopeing someone can help me out here. Thanks in advance :)
PS: My PC is "Windows 10 pro" 64 bit. If it matters.
SQLite is an embedded database; it does not run as a separate server process, but is a library that is usually compiled directly into the application itself.
Running the sqlite3 command-line shell does not make sense, because the version of the SQLite library compiled into that is not necessarily related to the version compiled into the Ruby gem. The guide you linked to is wrong; just ignore that point.
(But if you want to test SQL queries outside of Ruby, there's nothing wrong with installing and running sqlite3.exe.)
You do not need to install the DLL manually; any program that needed it would already ship with it.
For how to test the SQLite Ruby gem, see the sqlite3-ruby documentation.
Guide of what a path is and how to add stuff to it it. You may also want to consider using PostgreSQL as many members of the community prefer it over the packaged sqlite3.
These guys are also right about Ruby development kind of sucking on non-Unix systems though so if you plan on getting into this you might want to consider dual booting a Linux OS for development. You'll probably save yourself a lot of bugs.
I tried to install Perl 5.16 module 'Template-Toolkit' on windows 7 by using this command in cmd:
C:>ppm install Template-Toolkit
ppm install failed: Can't find any package that provides Template-Toolkit
All other modules I installed (AppConfig, DBI, DBD-mysql, MailTools, GD, Chart, GDGraph, ..) succeeded.
Following this webpage as a guide, they mention (under ActivateState Perl section) that you may not install Perl into a directory that contains a space (eg "C:\Program Files"), because it will break the Template-Toolkit installer. Since I installed Perl directly in 'C:\' -> 'C:\Perl64\', this could not be the case.
Is there a solution for this problem? Or should I use an older version of Perl, mentioned here?
The only errors in the error log are errors in the documentation (minor encoding issues).
The module could be installed safely. Just use cpan to do it. You'll just have to force the installation.
C:\>cpan
cpan> install Template
For me, that runs without issue. (The failing tests are skipped since they're dev-only tests.) If if fails for you and the only failures are the two errors from t/zz-pod-kwalitee.t, you can safely follow up with
cpan> force install Template
According to the ppm template-toolkit page, the build for ActiveState's Perl 5.16 failed (which is why it isn't available).
Your options seem to be:
Fix whatever bug is stopping it being built (it looks like it is just a couple of tests on the POD, so it could be an easy fix)
Use an older version of ActiveState Perl
Use a different distribution of Perl for Windows (such as Strawberry Perl)
Use a different operating system (e.g. Ubuntu in a virtual machine)
I got Warning and Error messages after these commands:
C:\>cpan
cpan> install Template
Please seen the screen shot below.
I haven't tried it myself but you can get Template::Alloy from the ActiveState PPM: http://metacpan.org/pod/Template::Alloy which claims it supports the TT2 syntax among others.
I've been unable to get plperl to work with Postgres 9.1 on Windows.
The same problem is described here, but with no solution so far:
http://postgresql.1045698.n5.nabble.com/BUG-6204-Using-plperl-functions-generate-crash-td4802111.html
REPRO
Install Perl 5.14 32-bit for Windows from here:
http://downloads.activestate.com/ActivePerl/releases/5.14.2.1402/ActivePerl-5.14.2.1402-MSWin32-x86-295342.msi
Add Perl to the system path variable
Install Postgres 9.1.2 32-bit for Windows from Enterprise DB
www.enterprisedb.com/products/pgdownload.do#windows
Now create a test DB, add perl to it, and try to create a function:
postgres=# create database plperl_test;
CREATE DATABASE
postgres=# \c plperl_test
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
You are now connected to database "plperl_test" as user "postgres".
plperl_test=# create language plperl;
CREATE LANGUAGE
plperl_test=# create function perl_test() returns void as
plperl_test-# $$
plperl_test$# $$
plperl_test-# language plperl;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
Note that this caused the Postgres server process to shut down. Yikes!
When I look in my Postgres log file, I find this...
2011-12-29 15:51:08 PST STATEMENT: create function perl_test() returns void as
$$
$$
language plperl;
2011-12-29 15:51:26 PST LOG: server process (PID 10364) was terminated by exception 0xC0000005
2011-12-29 15:51:26 PST HINT: See C include file "ntstatus.h" for a description of the hexadecimal value.
2011-12-29 15:51:26 PST LOG: terminating any other active server processes
2011-12-29 15:51:26 PST WARNING: terminating connection because of crash of another server process
2011-12-29 15:51:26 PST DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2011-12-29 15:51:26 PST HINT: In a moment you should be able to reconnect to the database and repeat your command.
2011-12-29 15:51:26 PST LOG: all server processes terminated; reinitializing
2011-12-29 15:51:36 PST FATAL: pre-existing shared memory block is still in use
2011-12-29 15:51:36 PST HINT: Check if there are any old server processes still running, and terminate them.
I was surprised to find no good answers from Google on this. It seems that Activstate works for some but not others. There were suspicions about conflicts with different versions of windows system libraries, but nothing definitive. However, I was able to finally build a plperl.dll that does work, using strawberry perl.
Here is step-by-painful step instructions to get plperl working with strawberry perl. The trick is to recompile postgresql and plperl, but install plperl over your existing postgresql install.
first, you will need the following:
mingw ( http://www.mingw.org )
strawberry perl. http://www.strawberryperl.org
Postgresql sources. Make sure you get the version that matches your install.
The mingw site is confusing as hell. There is no single package to download. You have to download an installer that downloads everything else. Here's a quick link to it.
http://sourceforge.net/projects/mingw/files/Installer/
In their installer, select both C and C++, and the MSYS environment to install. Mingw won't pollute your environment, so install it in any old location.
As for perl, I don't think activestate comes with the files (shared libraries) necessary to do this, and I've found strawberry's CPAN support to be superior (vs activestate's proprietary ppm sites) and activestate's douchebag move of putting old versions behind a paywall (and forcing other sites to takedown their hosted copies). F.U. ActiveState.
Postgresql 9.1 was originally built against perl 5.14, so it's probably best to stick with that version.
Unpack and install all that stuff. Mingw will give you a shell (look for the shortcut in the startup menu) to compile in. Start up a shell and do not close it.
run the following to install/remove packages:
mingw-get install libminizip
mingw-get remove mingw-perl
you need to remove mingw's perl so that the build process uses strawberry perl instead. You could screw around with the path variable instead, but this way is easier
now, you need to get to the directory that you unpacked the unpacked the postgresql sources to. In the mingw shell, use the root path /c to refer to the C: drive.
Now just configure and make
./configure --with-perl
make
Note that postgres docs say to use gmake, but on mingw, it's make.
The build will probably fail while building the actual plperl.dll file. That's because the build environment doesn't produce the right command to build the dll. If you get an error like this:
dllwrap -o plperl.dll --dllname plperl.dll --def libplperldll.def plperl.o SPI.o Util.o -L../../../src/port -Wl,--allow-multiple-definition -Wl,--as-needed -LC:/strawberry/perl/lib/CORE -l -L../../../src/backend -lpostgres
c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/ld.exe: cannot find -l-L../../../src/backend
c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/ld.exe: cannot find -lpostgres
cd to src/pl/plperl and execute the following command:
dllwrap -o plperl.dll --dllname plperl.dll --def libplperldll.def plperl.o SPI.o Util.o -L../../../src/port -Wl,--allow-multiple-definition -Wl,--as-needed -L/c/strawberry/perl/lib/CORE -L../../../src/backend -lpostgres -lperl514
(note that I have perl installed in c:\strawberry and mingw installed in c:\mingw )
At this point, you're done. you have a plperl.dll in that directory that can replace the one that comes with postgresql.
It says here, that (ActiveState) Perl 5.14 is required to get it working. I'm not sure about the brand as I had to use a legacy version of strawberry perl for postgres 9.0, which worked just fine. The important thing is to use the correct Perl version 5.14 for Postgres 9.1. Try to use a binary format (32 vs. 64 bit) matching the one of your postgres installation.
After playing around with a fresh installation of PostgreSQL 9.1.11 (x64) I've found ActivePerl 5.14.1 (x64) works. The key is to ensure that PostgreSQL can find the required perl DLL's in its environment PATH.
Run Dependency Walker on plperl.dll inside the postgres lib directory. In the case of PostgreSQL 9.1.11 it has a dependency on perl514.dll - so change your environment PATH to include the directory where this is located (i.e. c:\perl\bin). Recheck the DLL is detected properly by re-running Dependency Walker, then fully stop/start the PostgreSQL service you should be good to go.
If you find that the plperl.dll has a dependency on a different perl DLL then you need to use a version of ActivePerl that matches (i.e. perl58.dll would match ActivePerl 5.8, perl510.dll would match ActivePerl 5.10 - ensuring that the binary format of Perl and PostgreSQL always match (32/64bit)).
I have perl script which connects to an Oracle database, opens a text file and loads the data from the file in a database table, the script works perfectly on my development machine (windows xp 32 bit), however when i load the script to the production server (windows 2003 64 bit) and run it from a command line, it opens a perl.exe - unable to locate component windows, the message says
This application has failed to start because OCI.dll was not found. Re-installing the application may fix this problem.
The command line output is:
install_driver(Oracle) failed: Can't load
'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle:
load_file:%1 is not a valid Win32 application at
C:/Perl64/lib/DynaLoader.pm line 191. at (eval 14) line3 Compilation
failde in require at (eval 14) line 3. Perhaps a required shared
library or dll isn;t installde where expected at
c:\warranty\warrantyImport.pl line 15
I have reinstalled the oracle client, i have tried uninstalling both active perl and the oracle client and then installing the oracle client before perl as heard this might cause the issue.
I thought it could be permissions so i wrote a simple perl script to open to oci.dll and raised an error if unable, it was able to open it correctly.
I have ensured C:\oracle\product\10.2.0\client_1\bin is in the PATH enviroment variable.
I can connect to the database using SQLPlus
I have added the OCI.dll to the same directory as the perl script.
and i've now finally run out of ideas....can anyone suggest anything, i'm tearing my hair out trying to get it working.
Details
Server is running ActivePerl 5.14.1 Build 1401 (64-bit)
Oracle database is 10g
Oracle client is 10.2.0
I had a similar issue but for the 64bit version of Perl. I managed to resolve it by getting the correct client libraries and reading this guide:
http://www.pythian.com/news/11115/dbdoracle-and-windows-64bit/
Bascially, I’m running Oracle 11g XE R2, which only comes as 32bit. So I suspected that it was looking for the 64bit client libraries and not finding them. So I downloaded:
instantclient-basic-windows.x64-11.2.0.3.0.zip
instantclient-sqlplus-windows.x64-11.2.0.3.0.zip
instantclient-sdk-windows.x64-11.2.0.3.0.zip
From:
http://www.oracle.com/technetwork/topics/winx64soft-089540.html
And installed to c:\oraclexe\instantclient_11_2
I added these to my path:
C:>set PATH = c:\oraclexe\instantclient_11_2;%PATH%
But unfortunately the error persisted :(
On checking my PATH:
echo %PATH%
I could see that the set was getting ignored. I guess that was a permissions issue.
So I edited the system path variable and restarted the command prompt. This fixed the issue and allowed me to connect :)
Have you mixed some 32 bit and 64 bit components. Obviously you need 64 bit Perl, 64 bit DBI and DBD::Oracle and 64 bit dlls for Oracle client. I only suggest you check as the error says "is not a valid Win32 application at".
I've successfully installed native Oracle on 10.6, and can successfully compile and execute the example Pro*C code using the 'oracle' account (i.e. the same OS user that the software was installed under). That was a fun job. It even works with clang.
However, in our normal development environment, the source, build scripts, make files, etc, are owned by a different Unix group and user - with access to a restricted set of Oracle tools (sqlplus, exp, proc, etc).
Trying to use sqlplus from the oracle install gave the (known problem)
dyld: Library not loaded: /b/227/sqlplus/lib/libsqlplus.dylib
This is despite DYLD_LIBRARY_PATH definitely being set correctly. Someone who had done more investigation thought that somewhere along the line the library path was being unset before the process started.
I gave up and just went with using the instantclient instead.
Unfortunately, the instantclient SDK is OCCI only - it doesn't include the pro*c compiler.
So I am back to trying to get the 'dev' user to be able to execute 'proc' in the oracle bin directory. I've already solved one dylib issue (using a symbolic link), and various file permission issues (need to grant -r to files in the /precomp directory hierarchy).
Now I'm getting a core dump (which doesn't occur when running under the oracle user)
System default option values taken from:
/Users/oracle/product/10.2.0/db_1/precomp/admin/pcscfg.cfg
INTERNAL ERROR: Failed assertion [PGE Code=90105]
Segmentation fault
Any suggestions? Has anyone actually successfully done this?
The first problem I had was solved by granting read access to the /precomp directory and sub-directories under the oracle install (the question was then edited for my next problem).
By default the proc compiler writes into the directory where the source code file exists, not local. Simple fix - specify the target filename by path. This successfully produced the .c file.
Getting this to compile is a case of giving access to, and specifying, the right libraries to link in (the instantclient 64 bit ones will work here).
Finally, hack the example make into shape.