John,
Found this
http://e-docs.bea.com/platform/suppconfigs/configs70/hptru64unix51_alpha/70s
p1.html which explains the problem of the unresolved OCILobLocatorAssign.
I got our DBA to include OCILobLocatorAssign as an entrypoint in the list,
rebuilt libclntsh.so, and the build works OK now.
Sorry I did not get a chance to test this before the release, but I have had
a couple of problems building the new version, and any advice would be
welcome. So far I have:
Platform: Tru64 Unix V5.1 2650 alpha, native compiler
Oracle: 8.1.7
Perl: 5.8.7
Problem 1: cc: Error: Oracle.xs, line 269:
On Oracle 8.1.7
oerr ORA 24322
24322, 0, unable to delete an initialized mutex
// *Cause: An attempt to delete an initialized mutex failed.
// *Action: Contact customer support.
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 21 September 2005 7:19 PM
Not sure why you what the stored procedure looks like, but why are you using
the ref cursor both as a parameter and a return value? If it was a
procedure you would just have it an an IN OUT parameter, with just
BEGIN Package.Pr_Get_Config_System_Path(:p1,:out_cursor); END;
and vice versa if it
If you are trying to get output from a stored procedure, use something like:
#enable output
$dbh-func( 100, 'dbms_output_enable' );
#execute proc $sp
my $sth=$dbh-prepare($sp);
$sth-execute();
#retrieve output
my @text = $dbh-func( 'dbms_output_get' );
and @text contains what would
You would normally only expect $sth-{NAME} to be populated if the statement
handle was returning a result set, as in a SELECT statement.
BTW, as far as I know there in no point in the prepare/execute/finish
methods for the DDL stuff you are doing. These are used in DML type stuff
(select,
Daniel,
You haven't said what RDBMS you are using, but it looks to me like you need
to do the tuning there, and not in the DBI code.
If it was Oracle, I would not expect using functions like substr would cause
a performamce problem, but I would look at the query plan, and maybe try a
hint, eg
Patrick,
Its all in the documentation now (as in perldoc DBD::Oracle), but in case
this doesn't work for you it says:
To close the cursor you (currently) need to do this:
$sth3 = $dbh-prepare(BEGIN CLOSE :cursor END);
$sth3-bind_param_inout(:cursor, \$sth2, 0, { ora_type = ORA_RSET }
Chad,
You seem to have 4 bind variables but only need 3. Did you check the status
of the execute call (or have RaiseError set to 1)?
Michael Fox
-Original Message-
From: chad kellerman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 9 December 2003 9:04 AM
To: perl dbi
Subject: problems with
Dave,
Not real sure; you seem to have done it as per the examples in the doco
(
I just use bind_param for the close cursor, not bind_param_inout. And I use
it with a stored procedure, as in:
$sql = BEGIN dwh_util.ref_cursor_close(:curref); END;;
$sth = $dbh-prepare($sql);
If you are not worried about the order in which the columns come back, you
could select straight into a hash and save a few lines of code - something
like this:
my $r_results=$dbh-selectrow_hashref(Select * from $tablename where
idnr=?,{},($somenumber));
foreach my $col_name (keys %$r_results)
1. always have
use strict;
use warnings;
at the top of your program to trap any perl syntax errors - eg you declared
$go twice
2. At least have PrintError on (preferably RaiseError) to trap any Oracle
errors, as your insert command is incorrect syntax
3. Look at using placeholders rather
From what I can see, you just have the print in the wrong place. Each step
of the fetch loop, as it gets the names one by one, you push to the names
array, then print the array - so you see it each step of the way. Move the
print to outside the loop
-Original Message-
From: chad
its a slightly obscure combination of parameters, but when I set
ora_ph_type=96, my dbms_output from Oracle stored procedures disappeared.
Turns out this setting affected the parameter binding in sub dbms_output_get
in Oracle.pm, so that the return status from dbms_output.get_line is '0
'
When I need to have a use DBD::Oracle qw(:ora_types); in my program, and I
am running from cron, I get a message like:
Can't load 'long path/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle:'
at the use DBD::Oracle line.
Other programs that just have a 'use DBI' are fine. The normal program
Nope,
just set it directly on the statement handle
$sth-{RaiseError} = 1
instead of on the parent $dbh
-Original Message-
From: Mark Dedlow [mailto:mtdedlow;lbl.gov]
Sent: Thursday, October 24, 2002 1:06 PM
To: Dbi-Users
Subject: RaiseError sticks with statement handle??
RaiseError
Bill,
I don't have exactly your problem, but I run perl 5.6 and Oracle 8.1.7 on
Tru64 V4.0 and V5.1. I do not have root priviledges either, but I have
built perl, DBI and some of the DBD modules without any problems. Just
choose a 'good' prefix when you build perl. As I want the same perl/DBI
1. the prepare is missing, so $sth is not defined
2. the quoting loop is probably not doing what you want (its quoting the
tempoary variable field, not the elements of @ins) - but with placeholders
you probably don't want the fields quoted anyway
-Original Message-
From: Dolan, Mark
Not to sure what your function tims.get_all_curr_descs_items looks like, but
this (simple but possibly dumb) example worked for me:
use strict;
use warnings;
use DBI;
use DBD::Oracle qw(:ora_types);
my $dbh;
my $username='';
my $password='';
$ENV{ORACLE_SID}='dwhx01';
my
coredump
Michael Fox
-Original Message-
From: Rozengurtel, Daniel [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 21, 2002 12:02 AM
To: 'Fox, Michael'; '[EMAIL PROTECTED]'
Subject: RE: Stored Procs
I did that Mike but I get a Segmentation Fault(coredump)
any ideas?
Thanx
-Original
Any thoughts on using the new DBI feature, specifying maxrows in a
fetchall_arrayref?
If I use something like
while ( my $array_ref=$sth-fetchall_arrayref(undef, $maxfetch)) {
# ... do something
}
I get an inactive handle and an error on the last time through the loop.
Currently I am
It depends what Oracle's default date format is. Eg it could be MMDD,
but you are trying to insert a string with date and time. Work out what
Oracle date format your character string is in, then either use something
like:
$dbh-do(ALTER SESSION SET NLS_DATE_FORMAT = 'MMDDHH24MISS');
to
Paul,
I have:
Perl 5.6.0
DBI 1.21
DBD-Oracle 1.12
Oracle 8.1.7
on both Compaq Tru64 Unix versions 4.0 and 5.1
They both work fine. I have noticed I get the same error as you if
LD_LIBRARY_PATH is not set to $ORACLE_HOME/lib - don't know if this is your
problem??
Michael Fox
-Original
You disconnected after the first ping, so the second ping failed as the
output showed.
The second version just handled this condition, and went on to excute the
next statement, ie 'Finished work' not 'OK2'
-Original Message-
From: Andrei A. Voropaev [mailto:[EMAIL PROTECTED]]
Sent:
We are running OK with Oracle 8.1.7 on a Compaq alpha (Unix 5.1), using
DBI-1.20
DBD-Oracle-1.12
There were some issues with building DBD originally as Oracle had rearranged
their standard installation directory structure at 8.1.7, but these have all
been fixed in the current DBD
-Original
BTW: is that a typo? ORALCE_HOME vs ORACLE_HOME
-Original Message-
From: Kawai,Takanori [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 24, 2001 6:57 PM
To: Maruti Chavan; [EMAIL PROTECTED]
Subject: Re: Oracle Perl and DBI , dbd problem while inserting report in
Japanese
Hi.
#If you
More specifically, you enable DBMS output with a private database handle
function like (just setting another attribute on the database handle):
$dbh-func( 100, 'dbms_output_enable' );
and after the procedure is executed use something like
my @text = $dbh-func( 'dbms_output_get' );
to
I am in a similar position - migrating huge amounts of shell scripts, sql
scripts and PL/SQL programs to Perl/DBI (Oracle - Data warehousing
environment)
Apart from the PRO's already mentioned, I find that Perl/DBI reduces the
number of lines of code considerably, and also the number of program
Ronald,
I cannot reproduce your problem, but you might want to try altering the
session date format, rather than using to_date, as in
my $sqld=ALTER SESSION SET NLS_DATE_FORMAT = '-MM-DD';
$dbh-do($sqld);
and just use a string placeholder ? instead of to_date(?,'-MM-DD') in
the SQL
I see this has come up before, but looking at the archives it does not seem
to have been properly resolved.
Inserting a string containing only blanks into a NOT NULL column gives an
error, as in the example (note: the third insert is actually trying to
insert a single space character):
]]
Sent: Wednesday, May 02, 2001 10:38 AM
To: ''Fox, Michael ' '; [EMAIL PROTECTED]
Subject: RE: Oracle behaviour when inserting strings containing only
blanks
Guess you gotta use ' \0' if you use ora_ph_type = 5
Try it, let us know.
Ilya Sterin
-Original Message-
From: Michael A. Chase
31 matches
Mail list logo