Re: question for DBD-Oracle driver
On 2008-04-09 13:07:55 -0500, James H. McCullars wrote:
At 10:47 AM 4/9/2008, pgodfrin wrote:
This will obviate the need to use LD_LIBRARY_PATH, which has some
controversy surrounding it's use. I also found a strangeness for the
install of DBD. If I remember correctly, the install document states
that LD_LIBRARY_PATH should be set during the module install, which
will link the value of the LD_LIBRARY_PATH . Indeed the value ends up
in the make file (in the EXTRA_LIBS, LD_RUN_PATH and OTHERLDFLAGS
entries), and the library seems to be available as per the ldd
command, yet, without either an LD_LIBRARY_PATH environment variable
or the ld.so.conf.d method, DBD does not run.
I've just been through an install of DBD::Oracle on a Solaris 10 machine
and
this was my experience as well. My needs were complicated by the fact that I
was running it as a CGI script and thus did not have a way to easily set an
environment variable.
$ENV{LD_LIBRARY_PATH} = ...;
or somewhat more generic:
if (open(E, $offl_root/dbi/env)) {
while (E) {
chomp;
my ($k, $v) = split(/=/);
$ENV{$k} = $v;
}
close(E);
}
hp
--
_ | Peter J. Holzer| If I wanted to be academically correct,
|_|_) | Sysadmin WSR | I'd be programming in Java.
| | | [EMAIL PROTECTED] | I don't, and I'm not.
__/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users
pgpMmnG10yfux.pgp
Description: PGP signature
DB2.xs error
Hi, I'm trying to install DBD::DB2 1.0 onto AIX 5.3. perl makefile.pl runs ok but when I run make, I get this error DB2.xs, line 115.9: 1506-025 (S) Operand must be a modifiable lvalue. DB2.xs, line 175.13: 1506-025 (S) Operand must be a modifiable lvalue. make: 1254-004 The error code from the last command is 1. Any suggestions? Thanks, Simon Simon Cheng | Environment Support [EMAIL PROTECTED] phone: tie line: cell: 1-778-327-7846 327-7846 1-604-728-0999 www.ibm.com/services/innovation/ image/gif
Re: question for DBD-Oracle driver
On Apr 9, 1:07 pm, [EMAIL PROTECTED] (James H. McCullars) wrote: At 10:47 AM 4/9/2008, pgodfrin wrote: This will obviate the need to use LD_LIBRARY_PATH, which has some controversy surrounding it's use. I also found a strangeness for the install of DBD. If I remember correctly, the install document states that LD_LIBRARY_PATH should be set during the module install, which will link the value of the LD_LIBRARY_PATH . Indeed the value ends up in the make file (in the EXTRA_LIBS, LD_RUN_PATH and OTHERLDFLAGS entries), and the library seems to be available as per the ldd command, yet, without either an LD_LIBRARY_PATH environment variable or the ld.so.conf.d method, DBD does not run. Any thoughts? pg I've just been through an install of DBD::Oracle on a Solaris 10 machine and this was my experience as well. My needs were complicated by the fact that I was running it as a CGI script and thus did not have a way to easily set an environment variable. If you set LD_LIBRARY_PATH (or maybe LD_RUN_PATH) while doing the module build, then Oracle.so will be compiled with the paths to the modules it needs. But at runtime, it will load (on my system) libclntsh.so.10.1 which it finds in the oracle instant client directory. But then libclntsh.so.10.1 will want to load libnnz10.so and will not be able to because libclntsh.so.10.1 was compiled with a run path of whatever machine the Oracle client was compiled on. So what I wound up doing was just symlinking libnnz10.so to /usr/lib and I could then get my script to run without any runtime load paths. Hope this helps... Jim McCullars University of Alabama in Huntsville hmmm - running ldd on libclntsh.so gives me this: linux-gate.so.1 = (0x0011) libnnz10.so = /oracle/product/10.2.0.3/lib/libnnz10.so (0x00111000) libdl.so.2 = /lib/libdl.so.2 (0x00317000) libm.so.6 = /lib/libm.so.6 (0x0031c000) libpthread.so.0 = /lib/libpthread.so.0 (0x00345000) libnsl.so.1 = /lib/libnsl.so.1 (0x0035e000) libc.so.6 = /lib/libc.so.6 (0x00377000) /lib/ld-linux.so.2 (0x00687000) I'm running a Fedora 8 box - 10.2.0.3 Oracle install... pg
Multiple selectrow_array calls with statement handle error
With DBI 1.602 and DBD::Sybase 1.08 I get:
Can't locate object method DELETE via package DBI::st
on the second selectrow_array call.
If I replace $sth with $sql in the selectrow_array calls, then it
works correctly.
I did find a similar problem here:
http://www.nntp.perl.org/group/perl.dbi.users/2007/06/msg31486.html
but I thought that was fixed (did it get unfixed? :-)
I get the same error whether or not I have placeholders and bind parameters.
Here's the code:
use DBI;
my $dbh = DBI-connect(
'dbi:Sybase:server=SERVERNAME;database=dbname',
'user_name', 'password', {
RaiseError = 1,
});
my $sql = 'select some_column from my_table where my_id = ?';
my $sth = $dbh-prepare($sql);
my $id = 10600;
my $total;
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
Re: DB2.xs error
Simon Cheng wrote: Hi, I'm trying to install DBD::DB2 1.0 onto AIX 5.3. perl makefile.pl runs ok but when I run make, I get this error DB2.xs, line 115.9: 1506-025 (S) Operand must be a modifiable lvalue. DB2.xs, line 175.13: 1506-025 (S) Operand must be a modifiable lvalue. make: 1254-004 The error code from the last command is 1. Any suggestions? Please contact the group that supports DBD::DB2 - the mail address is [EMAIL PROTECTED], the same company and country that you are in :-) Thanks, Simon Simon Cheng | Environment Support [EMAIL PROTECTED] phone: tie line: cell: 1-778-327-7846 327-7846 1-604-728-0999 www.ibm.com/services/innovation/
Re: Multiple selectrow_array calls with statement handle error
Hi Douglas,
my 'perldoc DBI' (VERSION=1.43) says:
# @row_ary = $dbh-selectrow_array($statement, \%attr, @bind_values);
# This utility method combines prepare, execute and fetchrow_array
# into a single call.
According to this
* it is correct to use your $sql
* there is no need to prepare the statement
Has this changed since V. 1.43?
Yours,
Christian Merz
Douglas Wilson schrieb:
With DBI 1.602 and DBD::Sybase 1.08 I get:
Can't locate object method DELETE via package DBI::st
on the second selectrow_array call.
If I replace $sth with $sql in the selectrow_array calls, then it
works correctly.
I did find a similar problem here:
http://www.nntp.perl.org/group/perl.dbi.users/2007/06/msg31486.html
but I thought that was fixed (did it get unfixed? :-)
I get the same error whether or not I have placeholders and bind parameters.
Here's the code:
use DBI;
my $dbh = DBI-connect(
'dbi:Sybase:server=SERVERNAME;database=dbname',
'user_name', 'password', {
RaiseError = 1,
});
my $sql = 'select some_column from my_table where my_id = ?';
my $sth = $dbh-prepare($sql);
my $id = 10600;
my $total;
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
Re: question for DBD-Oracle driver
At 02:17 AM 4/10/2008, Peter J. Holzer wrote:
I've just been through an install of DBD::Oracle on a Solaris
10 machine and
this was my experience as well. My needs were complicated by the
fact that I
was running it as a CGI script and thus did not have a way to
easily set an
environment variable.
$ENV{LD_LIBRARY_PATH} = ...;
That doesn't work from a CGI script.
Jim McCullars
University of Alabama in Huntsville
Re: DB2.xs error
On Thu, Apr 10, 2008 at 5:01 AM, Hildo Biersma [EMAIL PROTECTED] wrote: Simon Cheng wrote: I'm trying to install DBD::DB2 1.0 onto AIX 5.3. perl makefile.pl runs ok but when I run make, I get this error DB2.xs, line 115.9: 1506-025 (S) Operand must be a modifiable lvalue. DB2.xs, line 175.13: 1506-025 (S) Operand must be a modifiable lvalue. make: 1254-004 The error code from the last command is 1. Any suggestions? Please contact the group that supports DBD::DB2 - the mail address is [EMAIL PROTECTED], the same company and country that you are in :-) Over and above what Hildo says, you should at the minimum identify whether you are modifying the system's install of Perl (generally a bad idea) or whether you are using your own version. You should also give at the least the version of Perl you are using and probably the full 'perl -V' output. You should also identify which version of the C compiler you are using, and which version of the DB2 CLI you are using. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: question for DBD-Oracle driver
On 2008-04-10 08:27:06 -0500, James H. McCullars wrote:
At 02:17 AM 4/10/2008, Peter J. Holzer wrote:
I've just been through an install of DBD::Oracle on a Solaris 10
machine and this was my experience as well. My needs were
complicated by the fact that I was running it as a CGI script and
thus did not have a way to easily set an environment variable.
$ENV{LD_LIBRARY_PATH} = ...;
That doesn't work from a CGI script.
Yes, it does. I have quite a few CGI scripts which use this technique.
Why shouldn't it work with a CGI script? I can think of reasons why it
wouldn't work with mod_perl, but none for a CGI script.
hp
--
_ | Peter J. Holzer| If I wanted to be academically correct,
|_|_) | Sysadmin WSR | I'd be programming in Java.
| | | [EMAIL PROTECTED] | I don't, and I'm not.
__/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users
pgp0etRPl9f3Z.pgp
Description: PGP signature
Re: question for DBD-Oracle driver
On Thu, 2008-04-10 at 16:08 +0200, Peter J. Holzer wrote:
On 2008-04-10 08:27:06 -0500, James H. McCullars wrote:
At 02:17 AM 4/10/2008, Peter J. Holzer wrote:
I've just been through an install of DBD::Oracle on a Solaris 10
machine and this was my experience as well. My needs were
complicated by the fact that I was running it as a CGI script and
thus did not have a way to easily set an environment variable.
$ENV{LD_LIBRARY_PATH} = ...;
That doesn't work from a CGI script.
Yes, it does. I have quite a few CGI scripts which use this technique.
Why shouldn't it work with a CGI script? I can think of reasons why it
wouldn't work with mod_perl, but none for a CGI script.
hp
I believe that LD_LIBRARY_PATH must already be set when the driver gets
loaded, so if it is not working, try setting it before using
DBI-connect().
Ulisses
Re: Multiple selectrow_array calls with statement handle error
On Wed, Apr 09, 2008 at 04:29:48PM -0700, Douglas Wilson wrote:
With DBI 1.602 and DBD::Sybase 1.08 I get:
Can't locate object method DELETE via package DBI::st
on the second selectrow_array call.
If I replace $sth with $sql in the selectrow_array calls, then it
works correctly.
I did find a similar problem here:
http://www.nntp.perl.org/group/perl.dbi.users/2007/06/msg31486.html
but I thought that was fixed (did it get unfixed? :-)
I get the same error whether or not I have placeholders and bind parameters.
Here's the code:
use DBI;
my $dbh = DBI-connect(
'dbi:Sybase:server=SERVERNAME;database=dbname',
'user_name', 'password', { RaiseError = 1 });
my $sql = 'select some_column from my_table where my_id = ?';
my $sth = $dbh-prepare($sql);
my $id = 10600;
my $total;
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
Code looks fine (it's okay to use an $sth instead of sql for the first arg).
Looks like a driver bug at first sight.
A DBI trace should shed more light on it.
Tim.
Re: question for DBD-Oracle driver
At 09:08 AM 4/10/2008, Peter J. Holzer wrote: Why shouldn't it work with a CGI script? I can think of reasons why it wouldn't work with mod_perl, but none for a CGI script. Setting the environment variable worked for me from the command line but never from a CGI script. The best explanation I could find for this was here: http://www.perlmonks.org/?node_id=126575 Since I didn't really want to fork a child process with every script execution, I just symlinked the library into /usr/lib. Problem solved. Jim McCullars University of Alabama in Huntsville
Re: question for DBD-Oracle driver
On 2008-04-10 10:26:50 -0500, James H. McCullars wrote: At 09:08 AM 4/10/2008, Peter J. Holzer wrote: Why shouldn't it work with a CGI script? I can think of reasons why it wouldn't work with mod_perl, but none for a CGI script. Setting the environment variable worked for me from the command line but never from a CGI script. By worked for me from the command line do mean: 1) Set the environment variable within the script as in the example I gave and invoked the script from the command line, or 2) set the environment variable in the shell and then invoke the script? These are completely different. The best explanation I could find for this was here: http://www.perlmonks.org/?node_id=126575 This talks about the second case. Yes, that's entirely possible (doesn't seem to be the case on linux, though), but it doesn't have anything to do with CGI scripts. I don't believe that that the first case is possible on any unixoid OS. hp -- _ | Peter J. Holzer| If I wanted to be academically correct, |_|_) | Sysadmin WSR | I'd be programming in Java. | | | [EMAIL PROTECTED] | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users pgpkNp51MjdpU.pgp Description: PGP signature
Re: Multiple selectrow_array calls with statement handle error
To Christian Merz: I'm executing this 1000's of times in the actual code, that is why I've prepared the query rather than passing in the sql string every time. For now I am just calling execute(), fetchrow_array(), and finish() explicitly. Below find the trace output: On Thu, Apr 10, 2008 at 7:54 AM, Tim Bunce [EMAIL PROTECTED] wrote: On Wed, Apr 09, 2008 at 04:29:48PM -0700, Douglas Wilson wrote: with trace(9) $dbh-trace(9); my $total; ( $total ) = $dbh-selectrow_array( $sth, undef, $id ); ( $total ) = $dbh-selectrow_array( $sth, undef, $id ); A DBI trace should shed more light on it. trace output: DBI::db=HASH(0x401aae68) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.602-nothread (pid 1812) - selectrow_array for DBD::Sybase::db (DBI::db=HASH(0x401aaef8)~0x401aae68 DBI::st=HASH(0x401ab0d8) undef 10600) bind :p1 == '10600' (attribs: ) bind :p1 () == 10600 (size 5/8/0, ptype 6, otype 0) bind :p1 == '10600' (size 7, ok 1) datafmt: type=8, name=, status=256, len=4 saved type: 8 cmd_execute() - ct_send() OK cmd_execute() - set inUse flag st_next_result() - ct_results(4040) == 1 ct_res_info() returns 1 columns STORE DBI::st=HASH(0x401ab0d8) 'NUM_OF_FIELDS' = 1 ct_describe(0): type = 10, maxlen = 8 describe() - col 0, type 10, realtype 10 describe() retcode = 1 st_next_result() - lasterr = 0, lastsev = 0 dbih_setup_fbav alloc for 1 fields dbih_setup_fbav now 1 fields syb_st_fetch() - ct_fetch() = -204 (0 rows, 1 cols) st_next_result() - ct_results(4046) == 1 st_next_result() - ct_results(4047) == 1 st_next_result() - ct_results(4046) == 1 ct_results(4046) final retcode = -205 st_next_result() - lasterr = 0, lastsev = 0 st_next_result() - got CS_CMD_DONE: resetting ACTIVE, moreResults, dyn_execed, exec_done clear_sth_flags() - resetting ACTIVE, moreResults, dyn_execed, exec_done clear_sth_flags() - reset inUse flag syb_st_fetch() - st_next_results() == 4046 clear_sth_flags() - resetting ACTIVE, moreResults, dyn_execed, exec_done clear_sth_flags() - reset inUse flag - selectrow_array= ( ) [0 items] at ./tst line 22 - selectrow_array for DBD::Sybase::db (DBI::db=HASH(0x401aaef8)~0x401aae68 DBI::st=HASH(0x401ab0d8) undef 10600) bind :p1 == '10600' (attribs: ) bind :p1 () == 10600 (size 5/8/7, ptype 6, otype 0) bind :p1 == '10600' (size 7, ok 1) datafmt: type=8, name=, status=256, len=4 saved type: 8 cmd_execute() - ct_send() OK cmd_execute() - set inUse flag st_next_result() - ct_results(4040) == 1 Can't locate object method DELETE via package DBI::st at ./tst line 23. ! - DESTROY for DBD::Sybase::db (DBI::db=HASH(0x401aae68)~INNER) syb_db_disconnect() - ct_close() ! - DESTROY= undef during global destruction
Re: Multiple selectrow_array calls with statement handle error
On Thu, Apr 10, 2008 at 11:15:30AM -0700, Douglas Wilson wrote:
$dbh-trace(9);
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
A DBI trace should shed more light on it.
Thanks. I believe this was fixed in DBI 1.57 (svn rev 9639) June 2007
Fixed XS versions of select*_*() methods to call execute()
fetch() etc., with inner handle instead of outer.
Are you *certain* that that code is running with DBI 1.602?
Try adding a print of $DBI::VERSION.
If you are stuck on an old DBI version try something like this as
a workaround:
sub DBI::st::DELETE { my ($h, $key) = @_; delete $h-{$key} }
Tim.
Re: Multiple selectrow_array calls with statement handle error
On Apr 10, 1:15 pm, [EMAIL PROTECTED] (Douglas Wilson) wrote: To Christian Merz: I'm executing this 1000's of times in the actual code, that is why I've prepared the query rather than passing in the sql string every time. For now I am just calling execute(), fetchrow_array(), and finish() explicitly. Below find the trace output: On Thu, Apr 10, 2008 at 7:54 AM, Tim Bunce [EMAIL PROTECTED] wrote: On Wed, Apr 09, 2008 at 04:29:48PM -0700, Douglas Wilson wrote: with trace(9) $dbh-trace(9); my $total; ( $total ) = $dbh-selectrow_array( $sth, undef, $id ); ( $total ) = $dbh-selectrow_array( $sth, undef, $id ); A DBI trace should shed more light on it. trace output: DBI::db=HASH(0x401aae68) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.602-nothread (pid 1812) - selectrow_array for DBD::Sybase::db (DBI::db=HASH(0x401aaef8)~0x401aae68 DBI::st=HASH(0x401ab0d8) undef 10600) bind :p1 == '10600' (attribs: ) bind :p1 () == 10600 (size 5/8/0, ptype 6, otype 0) bind :p1 == '10600' (size 7, ok 1) datafmt: type=8, name=, status=256, len=4 saved type: 8 cmd_execute() - ct_send() OK cmd_execute() - set inUse flag st_next_result() - ct_results(4040) == 1 ct_res_info() returns 1 columns STORE DBI::st=HASH(0x401ab0d8) 'NUM_OF_FIELDS' = 1 ct_describe(0): type = 10, maxlen = 8 describe() - col 0, type 10, realtype 10 describe() retcode = 1 st_next_result() - lasterr = 0, lastsev = 0 dbih_setup_fbav alloc for 1 fields dbih_setup_fbav now 1 fields syb_st_fetch() - ct_fetch() = -204 (0 rows, 1 cols) st_next_result() - ct_results(4046) == 1 st_next_result() - ct_results(4047) == 1 st_next_result() - ct_results(4046) == 1 ct_results(4046) final retcode = -205 st_next_result() - lasterr = 0, lastsev = 0 st_next_result() - got CS_CMD_DONE: resetting ACTIVE, moreResults, dyn_execed, exec_done clear_sth_flags() - resetting ACTIVE, moreResults, dyn_execed, exec_done clear_sth_flags() - reset inUse flag syb_st_fetch() - st_next_results() == 4046 clear_sth_flags() - resetting ACTIVE, moreResults, dyn_execed, exec_done clear_sth_flags() - reset inUse flag - selectrow_array= ( ) [0 items] at ./tst line 22 - selectrow_array for DBD::Sybase::db (DBI::db=HASH(0x401aaef8)~0x401aae68 DBI::st=HASH(0x401ab0d8) undef 10600) bind :p1 == '10600' (attribs: ) bind :p1 () == 10600 (size 5/8/7, ptype 6, otype 0) bind :p1 == '10600' (size 7, ok 1) datafmt: type=8, name=, status=256, len=4 saved type: 8 cmd_execute() - ct_send() OK cmd_execute() - set inUse flag st_next_result() - ct_results(4040) == 1 Can't locate object method DELETE via package DBI::st at ./tst line 23. ! - DESTROY for DBD::Sybase::db (DBI::db=HASH(0x401aae68)~INNER) syb_db_disconnect() - ct_close() ! - DESTROY= undef during global destruction Two questions, do you have RaiseError set anywhere? (I see no explicit error checking) And - could there be only one row of data? phil
