See this Blog entry for a similar story

http://www.pythian.com/news/6087/dbdoracle-on-aix-5-1/

sounds the same as yours

xlc: 1501-228 (W) input file /lib32/crt0_64.o not found
make: 1254-004 The error code from the last command is 252.

Stop.

The key problem was that 11g Client does not have the .mk files that the perl modules usually look for. I’m also curious if perl or Oracle 11g Client is in 32-bit, and if that has any negative impact.

See below for more details. Keep in mind, I’m not a perl developer, I only try to install the modules for our app. So, much of my explanation below is just from deduction. If someone has better input, please feel free to add.

- – -

Key changes:
• DBD::Oracle 1.19
• Use 11g Client’s .mk file demo_rdbms32.mk

What’s the story?

The DBD Modules have three key pieces
A) List of Oracle .mk files to look for (defined in Makefile.PL > mk_oci)
B) New features
C) Battery of tests

DBD::Oracle versions 1.19, 1.21, and 1.23 look for files a certain set of Oracle files (demo_xe.mk, oracle.mk, demo_rdbms.mk, ins_rdbms.mk,etc.). However, Oracle 11g Client install apparently does not have these files. The special Makefile.PL has some extra logic. If perl is 64-bit, then look for those usual set of files; otherwise, look for a single file, demo_rdbms32.mk. And the 11g Client has this file. You can specify this file as an argument, and that solves the problem too.

Why not 1.21? The “make test” only passes 96% of the tests
Why not 1.23? The “make test” only passes 6% of the tests

DBD 1.19 passes all the tests.

Steps

export ORACLE_HOME=
export ORACLE_SID=
export ORACLE_USERID=user/password@$ORACLE_SID
export PERLLIB=/usr/local/lib
export LIBPATH=$ORACLE_HOME/lib32
perl Makefile.PL -m $ORACLE_HOME/rdbms/demo/demo_rdbms32.mk
make
make test

Thanks

The JDBC interface does let you ‘batch’ multiple statments with one execute but this is just hiding the fact that one execute is fired for ecach of them.

From the JDBC docs

“The batch update facility is used with a PreparedStatement to associate multiple sets of input parameter values with a single PreparedStatement object.”

so this

PreparedStatement stmt = con.prepareStatement(
“INSERT INTO employees VALUES (?, ?)”);

stmt.setInt(1, 2000);
stmt.setString(2, “Kelly Kaufmann”);
stmt.addBatch();

stmt.setInt(1, 3000);
stmt.setString(2, “Bill Barnes”);
stmt.addBatch();

// submit the batch for execution
int[] updateCounts = stmt.executeBatch();

will do 1 OCIExecute .

but this

Statement stmt = con.createStatement();
stmt.addBatch(”INSERT INTO employees VALUES (1000, ?,?)”);
stmt.setInt(1, 2000);
stmt.setString(2, “Kelly Kaufmann”);
stmt.addBatch(”INSERT INTO departments VALUES (?, ?’)”);
stmt.setInt(1, 260);
stmt.setString(2, “Shoe”);
stmt.addBatch(”INSERT INTO emp_dept VALUES (?, ?)”);
stmt.setInt(1, 1000);
stmt.setInt(2, 260);

int[] updateCounts = stmt.executeBatch();

will do 3 OCIExecute command one for each SQL. So in this case there are 3 round trips to the server rather than just one for the last example.

‘Though it helps in array binding and helps it is not equivalent to the batching facility in java driver.’

Hi Laks I was curious about this so I had a look under the hood of the JDBC interface and which calls it was using in OCI to accomplish the task.

Well to my surprise both JDBC and DBD::Oracle use almost the exactly the same code under the hood so I think it is a case of ‘We do it this way any you do it the wrong way’:);).

In JDBC you
1) prepare a statement (con.prepareStatement)
2) bind values to the statement (stmt.setString(2, “bla”))
3) add the statement to a batch (stmt.addBatch())
4) repeat 2-3 above and then
5) execute your batch. (stmt.executeBatch())

in DBD:Oracle
1) prepare the statement ($dbh->prepare)
2) bind all the values to the statement ($sth->bind_param_array)
3) execute the statement. ($sth->execute_array)

In both JDBC and DBD::Oracle only 1 round trip call to the execute is made in OCI.

So me thinks it is a case here of ‘You say ‘potato’ and I say ‘potato’.

cheers