Unable to obtain a TAR-able binary image of DBI
Hi folks. I have a thread about this going on in comp.lang.perl.modules but this will probably get more reliable results. I have no trouble building perl 5.8.0 and the DBI 1.4.6 module on a development system with a compiler (and having just untarred into a virgin directory). I wish to create a TAR-able image so I can also install it on a box with no compiler. Following directions in the INSTALL file for perl itself, I included the option DESTDIR=... with the make install command. It performed as promised, creating a /usr/local.. hierarchy under the DESTDIR directory. Now I wished to do the same for DBI, similarly specifying a DESTDIR option on the make install command for dbi. In this case the DESTDIR remained empty. I have output of the first 3 steps as your README suggests. There is no need for make test VERBOSE=1 because the make test completed with no grief. I am, however, attaching the output of the make install to show what I was up to. Thanks for help here. perl Makefile.PL: db-perl.Makefile-PL.out make: DBI-make.out make test: DBI-make-test.out make install: DBI-make-install.out perl -V: perl-V.out +--- Jacob Salomon ([EMAIL PROTECTED]) --+ |Without question, the greatest invention in the history of mankind| |is beer. Oh, I grant you that the wheel was also a fine invention,| |but the wheel does not go nearly as well with pizza. | + Dave Barry -+ - This electronic mail message contains information that (a) is or may be CONFIDENTIAL, PROPRIETARY IN NATURE, OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named herein. If you are not an intended recipient, please send an email immediately to [EMAIL PROTECTED] and take the steps necessary to delete the message completely from your computer system. db-perl.Makefile-PL.out Description: Binary data DBI-make.out Description: Binary data DBI-make-test.out Description: Binary data DBI-make-install.out Description: Binary data perl-V.out Description: Binary data
Re: PERL DBI/DBD and Oracle encryption
Hallo ruimvelds, do you want to encrypt data. E.g. to store passwords. Or do you want to encrypt the communication? Friday, January 7, 2005, 5:51:24 PM, you wrote: r Does anyone know of an issue with Perl DBI and oracle encryption? cu Wielandmailto:[EMAIL PROTECTED]
Re: Unable to obtain a TAR-able binary image of DBI
On 01/10/2005 04:32 PM, Jacob Salomon said: I have no trouble building perl 5.8.0 and the DBI 1.4.6 module on a development system with a compiler (and having just untarred into a virgin directory). I wish to create a TAR-able image so I can also install it on a box with no compiler. Following directions in the INSTALL file for perl itself, I included the option DESTDIR=... with the make install command. It performed as promised, creating a /usr/local.. hierarchy under the DESTDIR directory. Now I wished to do the same for DBI, similarly specifying a DESTDIR option on the make install command for dbi. In this case the DESTDIR remained empty. Building perl and building a module are slightly different operations. DESTDIR= should be on the `perl Makemaker.PL` line, not the `make install` line. http://search.cpan.org/~mschwern/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm I have output of the first 3 steps as your README suggests. There is no need for make test VERBOSE=1 because the make test completed with no grief. I am, however, attaching the output of the make install to show what I was up to. Please be more specific what the problem is. It looks like DBI is being installed in the /usr/local/ hierarchy of the perl you intend to tar just like I would expect it to. DESTDIR isn't needed if that is adequate. If you want DBI to be somewhere else, try PREFIX=/dir/ or DESTDIR=/dir/ in the `perl Makefile.PL` line. -- Mac :}) ** I usually forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
RE: Can some one help me to install DBD::Oracle on Linux
1. Do you have Oracle client (at least) installed? 2. Did you read the README* files? - Ron Reidy Lead DBA Array BioPharma, Inc. -Original Message- From: Shiva kumar [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 11, 2005 12:24 AM To: dbi-users@perl.org Subject: Can some one help me to install DBD::Oracle on Linux Linux version: Linux agumbe.p.in.integral.com 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux Oracle client: 9.2.0 DBD::Oracle: DBD-Oracle-1.16 Following error when installing, I tried to locate oracle.mk but i couldnot find any such file Using Oracle in /cust/oraclient/9.2.0 DEFINE _SQLPLUS_RELEASE = 902000100 (CHAR) Oracle version 9.2.0.1 (9.2) Unable to locate an oracle.mk, proc.mk or other suitable *.mk file in your Oracle installation. (I looked in /cust/oraclient/9.2.0/rdbms/lib/oracle.mk /cust/oraclient/9.2.0/rdbms/demo/oracle.mk /cust/oraclient/9.2.0/rdbms/demo/demo_rdbms.mk /cust/oraclient/9.2.0/otrace/demo/atmoci.mk /cust/oraclient/9.2.0/precomp/demo/proc/proc.mk /cust/oraclient/9.2.0/precomp/demo/proc/demo_proc.mk /cust/oraclient/9.2.0/proc/lib/proc.mk /cust/oraclient/9.2.0/proc16/lib/proc16.mk) Please advise. __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
Oracle Instant Client 10.1.0.3 SDK and DBD::Oracle
Hi! The latest patch set (10.1.0.3) for the Oracle Instant Client 10g includes the long awaited SDK. I had a quick look at it, and it seems Oracle decided to put the header files in the traditional /usr/include and /usr/share directories. This won't work out of the box with DBD::Oracle, as it's tuned to having the header files available relative to $ORACLE_HOME. These are the current locations of the library and header files for the Instant Client 10g: [## oic]$ rpm -q -l -p oracle-instantclient-basic-10.1.0.3-1.i386.rpm /usr/lib/oracle/10.1.0.3/client/lib/classes12.jar /usr/lib/oracle/10.1.0.3/client/lib/libclntsh.so.10.1 /usr/lib/oracle/10.1.0.3/client/lib/libnnz10.so /usr/lib/oracle/10.1.0.3/client/lib/libocci.so.10.1 /usr/lib/oracle/10.1.0.3/client/lib/libociei.so /usr/lib/oracle/10.1.0.3/client/lib/libocijdbc10.so /usr/lib/oracle/10.1.0.3/client/lib/ojdbc14.jar [## oic]$ rpm -q -l -p oracle-instantclient-devel-10.1.0.3-1.i386.rpm /usr/include/oracle/10.1.0.3/client/nzerror.h /usr/include/oracle/10.1.0.3/client/nzt.h /usr/include/oracle/10.1.0.3/client/occi.h /usr/include/oracle/10.1.0.3/client/occiAQ.h /usr/include/oracle/10.1.0.3/client/occiCommon.h /usr/include/oracle/10.1.0.3/client/occiControl.h /usr/include/oracle/10.1.0.3/client/occiData.h /usr/include/oracle/10.1.0.3/client/occiObjects.h /usr/include/oracle/10.1.0.3/client/oci.h /usr/include/oracle/10.1.0.3/client/oci1.h /usr/include/oracle/10.1.0.3/client/oci8dp.h /usr/include/oracle/10.1.0.3/client/ociap.h /usr/include/oracle/10.1.0.3/client/ociapr.h /usr/include/oracle/10.1.0.3/client/ocidef.h /usr/include/oracle/10.1.0.3/client/ocidem.h /usr/include/oracle/10.1.0.3/client/ocidfn.h /usr/include/oracle/10.1.0.3/client/ociextp.h /usr/include/oracle/10.1.0.3/client/ocikpr.h /usr/include/oracle/10.1.0.3/client/ocixmldb.h /usr/include/oracle/10.1.0.3/client/odci.h /usr/include/oracle/10.1.0.3/client/oratypes.h /usr/include/oracle/10.1.0.3/client/ori.h /usr/include/oracle/10.1.0.3/client/orid.h /usr/include/oracle/10.1.0.3/client/orl.h /usr/include/oracle/10.1.0.3/client/oro.h /usr/include/oracle/10.1.0.3/client/ort.h /usr/include/oracle/10.1.0.3/client/xa.h /usr/lib/oracle/10.1.0.3/client/lib/libclntsh.so /usr/lib/oracle/10.1.0.3/client/lib/libocci.so /usr/share/oracle/10.1.0.3/client/cdemo81.c /usr/share/oracle/10.1.0.3/client/demo.mk /usr/share/oracle/10.1.0.3/client/occidemo.sql /usr/share/oracle/10.1.0.3/client/occidemod.sql /usr/share/oracle/10.1.0.3/client/occidml.cpp I imagine this requires a somewhat significant change to Makefile.PL, for DBD::Oracle to work with the new SDK? I'm wondering whether anybody is looking into this currently? I'd do it myself, but the Makefile.PL looks quite intimidating, and I'm by no means a Perl hacker. Any pointers would be appreciated however. :-) Cheers! Kim Nielsen
Upgrading Perl and Solaris on a unix box
All, This may not be the exact place to post this, but my issue started with DBD and DBI. I have inherited a Unix box with solaris 5.7 and Perl 5.6.0 installed. It was created in 2001. I have had problems accessing an Oracle 9i database. One recomendation was to install the 9i client on the box, but the 9i client software only has installation modules for solaris 5.8 and 5.9. So I am unable to link my current DBI (1.20) and DBD::Oracle (1.12) with the 9i clinet. People are recomending we upgrade the machine from solaris 5.7 to 5.9. If this were to be done, does this mean I would have to re-install all perl modules? Also if we upgrade to solaris 5.9, would it be reasonable to upgrade to a later version of Perl and if so what version. This whole trouble seems to spark around having PErl 5.6.0 on a solaris 5.7 machine, but I am not sure what the best recomendation to the problem is as I am not a system administrator and I don't understand the issues involved. any thoughts would be appreciated. Steve
Re: Which driver for SQL Server?
On Tue, 2005-01-11 at 08:05, Daniel Kasak wrote: Michael Peppler wrote: The FreeTDS ODBC drivers support placeholders, IIRC. Are you *sure*? That's what I'm using at the moment ... DBD::Sybase with FreeTDS. DBD::Sybase with FreeTDS does NOT support placeholders (yet). But FreeTDS also includes an ODBC driver which DOES support placeholders - so you should be able to use DBD::ODBC with a driver manager of some sort and FreeTDS's ODBC libraries with placeholders. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
MS Sql server - make test failures
I am using Fedora Core 2, Perl version 5.8.3 DBI version 1.46 and DBD::odbc 1.13. I am also using unixODBC version 2.2.10 to connect to a Microsoft SQL server 2000 (mdac 2.8 and SP3 installed) I am using freeTDS as the driver, latest stable version (I cant find the damn version number for it) While installing DBD::ODBC everything goes well. I use the following commands (after setting the DSN_* LD_LIBRARY_PATH and ODBCHOME env vars) perl Makefile.PL -o /usr/local/unixodbc make make test make test fails in several places. Sometimes with a compiler error (I fixed there, just areas where there was no check of undefined variables.) these errors have been corrected - they were all Uninitialized string variable ne, and they were all in 20SqlServer.t I have fixed these already, so I don't have the exact error codes. My question is this - the 20SqlServer.t test fails when it is doing the data comparison test. In the code it is inserting data into the db, and then reading it back to see if the data is the same. One of these lines of code is inserting 282 characters (d) into the db and then reading it back. It always returns 255 characters, even though it inserted 282. After much bug tracking, I have discovered that it seems fetchrow_array() seems to only return 256 characters at the max. It fails the test, not fails as in crashes/runtime error. Why is this, and how can I fix it? Thanks Dan Strohschein Dan Strohschein
Attempt to initiate a new SQL Server operation with results pending.
Hi all. I've just ( barely ) managed to get DBD::ODBC == UnixODBC == FreeTDS working on my system. I took a Perl-Gtk2 app which has been running fine, and substituted the old DBD::Sybase connection with the DBD::ODBC one, and then discovered I could only run one query on SQL Server, and then all subsequent queries gave: DBD::ODBC::st execute failed: [unixODBC][FreeTDS][SQL Server]Attempt to initiate a new SQL Server operation with results pending. (SQL-07005)(DBD: st_execute/SQLExecute err=-1) Damn! So I started going through my code and adding $sth-finish after all recordset operations, and that seems to be fixing things. Why is this happening? Surely if I loop through a recordset until the end, the drivers should figure out that there are no more results pending? That's at least what happens with all the other drivers I've used. Is there an alternative to adding $sth-finish at the end of each recordset operation? What happens if I have a sub that creates a $sth and loops through it and then exits. The $sth goes out of scope, right? Is this sufficient, or do I have to $sth-finish in these cases as well? Dan -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au
Re: Upgrading Perl and Solaris on a unix box
On 01/11/2005 07:26 AM, ruimvelds said: I have inherited a Unix box with solaris 5.7 and Perl 5.6.0 installed. It was created in 2001. I have had problems accessing an Oracle 9i database. One recomendation was to install the 9i client on the box, but the 9i client software only has installation modules for solaris 5.8 and 5.9. People are recomending we upgrade the machine from solaris 5.7 to 5.9. If this were to be done, does this mean I would have to re-install all perl modules? Probably, but it's a good time to ugrade everything in the Perl tree. I don't know any modules off hand that haven't changed since 2001. Also if we upgrade to solaris 5.9, would it be reasonable to upgrade to a later version of Perl and if so what version. The latest (5.8.6) unless someone has heard of any show-stoppers with it. This whole trouble seems to spark around having PErl 5.6.0 on a solaris 5.7 machine, but I am not sure what the best recomendation to the problem is as I am not a system administrator and I don't understand the issues involved. With so much that is so old, upgrading is almost a no brainer. The only thing that might stop you is if some of the old hardware is not supported by the newer version of the OS. -- Mac :}) ** I usually forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
ANNOUNCE: SQL-Interpolate 0.30
SQL-Interpolate is now available on CPAN:
SQL-Interpolate - Simplified interpolation of Perl variables into SQL
statements
http://search.cpan.org/~dmanura/SQL-Interpolate/
DESCRIPTION
SQL-Interpolate is collection of modules that make it easy to
interpolate Perl variables into SQL statements. It does so in a manner
that is often more natural and less redundant, error-prone and
restrictive than existing methods. SQL::Interpolate converts a list of
intermixed SQL fragments and variables into a conventional SQL string
and list of _bind values_, which can be used directly or passed onto DBI.
Probably anyone who uses placeholders and bind values for DBI calls can
use this module to improve the readability of one's code.
SYNOPSIS
# SQL::Interpolate basic usage
use SQL::Interpolate qw(:all);
my @colors = ('blue', 'green');
my($sql, @bind) = sql_interp
q[SELECT * FROM mytable WHERE color IN], [EMAIL PROTECTED],
q[AND y =], \$x, q[OR], {z = 3, w = 2} ;
# Result:
# $sql = SELECT * FROM mytable WHERE color IN (?, ?) .
# AND y = ? OR (z = ? AND w = ?);
# @bind = ('blue', 'green', $x, 3, 2);
# Passing any of the above results to DBI
$dbh-selectall_arrayref($sql, undef, @bind);
# DBIx::Interpolate module - Integrates SQL::Interpolate into DBI
use DBIx::Interpolate qw(:all);
my $dbx = new DBIx::Interpolate($dbh);
$dbx-selectall_arrayref(
q[SELECT * FROM table WHERE color IN], [EMAIL PROTECTED], q[AND y =], \$x
);
# SQL::Interpolate::Macro module - Macros and SQL Filters for
SQL::Interpolate
use SQL::Interpolate::Macro qw(:all);
sql_interp
q[SELECT * FROM mytable WHERE],
sql_and( sql_if($blue, q[color = blue]),
sql_if($shape, sql_fragment(q[shape =], \$shape)) ),
q[LIMIT 10];
# SQL::Interpolate::Filter - Source Filters for SQL::Interpolate
use SQL::Interpolate FILTER = 1, qw(:all);
($sql, @bind) = sql_interp sql[
SELECT * FROM mytable WHERE color IN @colors
AND y = $x OR {z = 3, w = 2}
];
There's many ways to call SQL-Interpolate. It can be used as a wrapper
for DBI, in conjunction with DBI, or without DBI at all; with a
functional interface and an OO one; and without or with source
filtering. All these methods revolve around a single, relatively simple
function, sql_interp().
This module was announced a year ago:
http://www.mail-archive.com/dbi-users@perl.org/msg19538.html
However, it has undergone an major refactoring in recent months. The
core module is simpler and more general. Non-essential functionality
has been moved into other modules and extended, and you can choose to
use these in any combination or not at all.
Any comments and suggestions for these modules are most welcome. I hope
this module can be widely used because it solves a very common
problem--the ugliness of interpolating variables with DBI--in a simple
and unobtrusive way.
-david manura, http://math2.org/sql_interpolate
What's up with this bit of code?
I'm trying to work around my inability to get last_insert_id to work for
various drivers...
The code below works for the 1st and 3rd case ( both of my MySQL setups
). It creates a code reference in $self-{last_insert_id} that I can
then call later.
However if I switch to my SQL Server setup ( driver name = ODBC ),
perl drops out of the sub after attempting to run the code inside the
condition part ( ie the 'return $self;' line doesn't execute ), and I
get the error:
Not a subroutine reference at ...
The code:
---
if ($self-{dbh}-{Driver}-{Name} eq mysql $DBD::mysql::VERSION
=2.9004) {
$self-{last_insert_id} = \ { $self-{dbh}-{'mysql_insertid'}; };
} elsif ($self-{dbh}-{Driver}-{Name} eq ODBC) {
$self-{last_insert_id} = \ {
my $sth = $self-{dbh}-prepare('select
@@IDENTITY');
$sth-execute;
if ($row = $sth-fetchrow_array) {
return $$row[0];
} else {
return 0;
}
}
} else {
$self-{last_insert_id} = \ { $self-{dbh}-last_insert_id };
}
return $self;
---
What's up with the code in my ODBC case?
--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [EMAIL PROTECTED]
website: http://www.nusconsulting.com.au
RE: Can some one help me to install DBD::Oracle on Linux
Hi All, Thanks for the response. Oracle client is installed and all environment variables set. Finally I resolved it by copying the rdbms/demo directory from oracle full installation Thanks Shiv --- Reidy, Ron [EMAIL PROTECTED] wrote: 1. Do you have Oracle client (at least) installed? 2. Did you read the README* files? - Ron Reidy Lead DBA Array BioPharma, Inc. -Original Message- From: Shiva kumar [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 11, 2005 12:24 AM To: dbi-users@perl.org Subject: Can some one help me to install DBD::Oracle on Linux Linux version: Linux agumbe.p.in.integral.com 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux Oracle client: 9.2.0 DBD::Oracle: DBD-Oracle-1.16 Following error when installing, I tried to locate oracle.mk but i couldnot find any such file Using Oracle in /cust/oraclient/9.2.0 DEFINE _SQLPLUS_RELEASE = 902000100 (CHAR) Oracle version 9.2.0.1 (9.2) Unable to locate an oracle.mk, proc.mk or other suitable *.mk file in your Oracle installation. (I looked in /cust/oraclient/9.2.0/rdbms/lib/oracle.mk /cust/oraclient/9.2.0/rdbms/demo/oracle.mk /cust/oraclient/9.2.0/rdbms/demo/demo_rdbms.mk /cust/oraclient/9.2.0/otrace/demo/atmoci.mk /cust/oraclient/9.2.0/precomp/demo/proc/proc.mk /cust/oraclient/9.2.0/precomp/demo/proc/demo_proc.mk /cust/oraclient/9.2.0/proc/lib/proc.mk /cust/oraclient/9.2.0/proc16/lib/proc16.mk) Please advise. __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system. __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
RE: Attempt to initiate a new SQL Server operation with results pending.
Hi all. I've just ( barely ) managed to get DBD::ODBC == UnixODBC == FreeTDS working on my system. I took a Perl-Gtk2 app which has been running fine, and substituted the old DBD::Sybase connection with the DBD::ODBC one, and then discovered I could only run one query on SQL Server, and then all subsequent queries gave: DBD::ODBC::st execute failed: [unixODBC][FreeTDS][SQL Server]Attempt to initiate a new SQL Server operation with results pending. (SQL-07005)(DBD: st_execute/SQLExecute err=-1) Damn! So I started going through my code and adding $sth-finish after all recordset operations, and that seems to be fixing things. Please see if you can provide a small, self-contained example. (i.e. one that creates tables and inserts data, then reproduces the problem, such that it can be run simply (or, feel free to add it to some of the DBD::ODBC t/20sqlserver.t tests, if you feel slightly more inclined), then I can refine the implementation to ensure that you don't have to call finish each time. It's supposed to be that way, but if it's not working, I'd like to know. Also, I thought that DBD::Sybase had some work around/automatic fix for multiple concurrent statements -- so it may be that you haven't finished retrieving all results, but DBD::Sybase is smarter about it. One final thing, try looking at DBD::ODBC's attribute: odbc_curstortype. See the pod in DBD::ODBC and example in t/20SqlServer.t Why is this happening? Surely if I loop through a recordset until the end, the drivers should figure out that there are no more results pending? That's at least what happens with all the other drivers I've used. Is there an alternative to adding $sth-finish at the end of each recordset operation? Yep, it should be, but if it isn't and you can provide a sample, I'll see if it can be fixed. What happens if I have a sub that creates a $sth and loops through it and then exits. The $sth goes out of scope, right? Is this sufficient, or do I have to $sth-finish in these cases as well? The sth going out of scope should do it too... Jeff
