Re: connecting()?
On Thu, Apr 15, 2010 at 10:07:14AM -0700, David E. Wheeler wrote:
On Apr 15, 2010, at 5:17 AM, Tim Bunce wrote:
$drh = DBI-install_driver($driver);
$dbh = $drh-connect(...);
Assuming we added a $dbh-connecting() method, how would it be called,
and how would the callback have been enabled prior to calling it?
In connect(), before $connect_meth, just as connected() is called in that
method after $connect_meth.
$dbh-connected(@orig_args);
unless ($dbh = $drh-$connect_meth($dsn, $user, $pass, $attr)) {
$dbh is undef before the $drh-$connect_meth call.
It's not my needs. Someone is creating a CPAN module I think. His
needs were met by connected(), but I think that connecting() would be
useful as well.
Perhaps but it sure seems like a low priority.
If we did that (and handled backwards compatibility somewhow)
then presumably new_child() could apply the Callbacks attribute
which would then fire on the subsequent $dbh-connect call.
That would be cool. I, alas, have a very short supply of tuits these days.
Ditto.
Tim.
Re: connecting()?
On Apr 16, 2010, at 3:13 AM, Tim Bunce wrote:
In connect(), before $connect_meth, just as connected() is called in that
method after $connect_meth.
$dbh-connected(@orig_args);
unless ($dbh = $drh-$connect_meth($dsn, $user, $pass, $attr)) {
$dbh is undef before the $drh-$connect_meth call.
Oh. Well that'd have to change.
It's not my needs. Someone is creating a CPAN module I think. His
needs were met by connected(), but I think that connecting() would be
useful as well.
Perhaps but it sure seems like a low priority.
I don't the tuits to do it, I admit.
That would be cool. I, alas, have a very short supply of tuits these days.
Ditto.
Is that what's holding back 1.610?
Best,
David
Re: connecting()?
On Fri, 16 Apr 2010 12:41:32 -0700, David E. Wheeler
da...@kineticode.com wrote:
On Apr 16, 2010, at 3:13 AM, Tim Bunce wrote:
In connect(), before $connect_meth, just as connected() is called in that
method after $connect_meth.
$dbh-connected(@orig_args);
unless ($dbh = $drh-$connect_meth($dsn, $user, $pass, $attr)) {
$dbh is undef before the $drh-$connect_meth call.
Oh. Well that'd have to change.
It's not my needs. Someone is creating a CPAN module I think. His
needs were met by connected(), but I think that connecting() would be
useful as well.
Perhaps but it sure seems like a low priority.
I don't the tuits to do it, I admit.
That would be cool. I, alas, have a very short supply of tuits these days.
Ditto.
Is that what's holding back 1.610?
There will be no 1.610
$ perl -MV=DBI
DBI
/pro/lib/perl5/site_perl/5.12.0/i686-linux-64int-ld/DBI.pm: 1.611
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: connecting()?
On Wed, Mar 31, 2010 at 10:14:04AM -0700, David E. Wheeler wrote:
Fellow DBIers,
I was just discussing writing a callback on connect() to change
authentication (my correspondent wants to use realm files). But then I
discovered to my disappointment that there is no support for callbacks
on connect(). This makes sense, frankly, since the method is called
before the callbacks are applied, and callbacks execute before the
method, not afterward (at least for now).
Yeap.
But I've found great use by adding callbacks on connected(), so that
they execute just after a connection. So I was wondering how folks
felt about the idea of adding a connecting() method that executes just
before the DBI tries to connect to the database? I think this would be
a nice complement to connecting(), and instantly make a simple
interface for adding a pre-connection callback, too.
DBI-connect effectively does:
$drh = DBI-install_driver($driver);
$dbh = $drh-connect(...);
Assuming we added a $dbh-connecting() method, how would it be called,
and how would the callback have been enabled prior to calling it?
Why not register the callback on the driver:
DBI-install_driver('Pg')-{Callbacks}{connect} = ...;
That'll affect all subsequent connects using that driver and won't work
with proxy drivers like Gofer, which is why DBI docs discourage messing
with driver handles, but it may fit your needs.
Tim.
p.s. On a slight tangent: most drivers implement $dbh-connect with code like:
my $this = DBI::_new_dbh($drh, ...);
It's long bugged me that this isn't a method call.
In http://cpansearch.perl.org/src/TIMB/DBI-1.609/TODO_2005.txt
(which is old but still has useful information) I suggested:
Rework handle creation to use methods:
Maybe $h-new_child(\%handle_attr)
dr::connect =
$dbh = $drh-new_child(\%attr);
$dbh-connect(...) - calls $dbh-reset()
db::prepare =
sub ...::db::prepare {
my ($dbh, $sql, $attr) = @_;
$sth = $dbh-new_child($attr)
my @statements = $dbh-preparse($sql);
$sth-{PendingStatements} = \...@statements if @statements 1;
$sth-prepare( shift @statements ) or return;
return $sth;
}
If we did that (and handled backwards compatibility somewhow)
then presumably new_child() could apply the Callbacks attribute
which would then fire on the subsequent $dbh-connect call.
Re: connecting()?
On Apr 15, 2010, at 5:17 AM, Tim Bunce wrote:
$drh = DBI-install_driver($driver);
$dbh = $drh-connect(...);
Assuming we added a $dbh-connecting() method, how would it be called,
and how would the callback have been enabled prior to calling it?
In connect(), before $connect_meth, just as connected() is called in that
method after $connect_meth.
$dbh-connected(@orig_args);
unless ($dbh = $drh-$connect_meth($dsn, $user, $pass, $attr)) {
Why not register the callback on the driver:
DBI-install_driver('Pg')-{Callbacks}{connect} = ...;
That'll affect all subsequent connects using that driver and won't work
with proxy drivers like Gofer, which is why DBI docs discourage messing
with driver handles, but it may fit your needs.
It's not my needs. Someone is creating a CPAN module I think. His needs were
met by connected(), but I think that connecting() would be useful as well.
If we did that (and handled backwards compatibility somewhow)
then presumably new_child() could apply the Callbacks attribute
which would then fire on the subsequent $dbh-connect call.
That would be cool. I, alas, have a very short supply of tuits these days.
Best,
David
connecting()?
Fellow DBIers, I was just discussing writing a callback on connect() to change authentication (my correspondent wants to use realm files). But then I discovered to my disappointment that there is no support for callbacks on connect(). This makes sense, frankly, since the method is called before the callbacks are applied, and callbacks execute before the method, not afterward (at least for now). But I've found great use by adding callbacks on connected(), so that they execute just after a connection. So I was wondering how folks felt about the idea of adding a connecting() method that executes just before the DBI tries to connect to the database? I think this would be a nice complement to connecting(), and instantly make a simple interface for adding a pre-connection callback, too. Thoughts? Best, David
Re: connecting()?
On Wed, 31 Mar 2010 10:14:04 -0700, David E. Wheeler
da...@kineticode.com wrote:
Fellow DBIers,
I was just discussing writing a callback on connect () to change
authentication (my correspondent wants to use realm files). But then I
discovered to my disappointment that there is no support for callbacks
on connect (). This makes sense, frankly, since the method is called
before the callbacks are applied, and callbacks execute before the
method, not afterward (at least for now).
But I've found great use by adding callbacks on connected (), so that
they execute just after a connection. So I was wondering how folks
felt about the idea of adding a connecting () method that executes just
before the DBI tries to connect to the database? I think this would be
a nice complement to connecting (), and instantly make a simple
interface for adding a pre-connection callback, too.
Thoughts?
All in favour, if not only to be able to use $ENV{DBD_VERBOSE} and
$ENV{DBI_VERBOSE} to set verbosity on connection before it even starts!
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Problem in connecting Perl with Oracle
Hello I've installed Perl 5.10 successfully and all other perl program running perfectly. But it's showing following problem when i'm trying to connect oracle Problem: 1. The procedure entry point OCIXML TypeCreateFromSrc could not be located in the dynamic link library OCI.dll. 2. install_driver(Oracle) failed: Can't load 'C:/Perl/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file: The specified procedure could not be found at C:/Perl/lib/DynaLoader.pm line 202 at (eval 4) line 3 Compilation failed in require at (level 4) line 3. Perhaps a required shared library or dll isn't installed where expected at dbi.pl line 3 See below mentioned coding from which I intended to connect Oracle (dbi.pl) use strict; use DBI; my $dbh = DBI-connect( 'dbi:Oracle:orcl','scott','tiger',)|| die Database connection not made: $DBI::errstr; $dbh-disconnect(); Thanks Kanhaiya Prasad Delhi
Re: Problem in connecting Perl with Oracle
You are using an older Oracle client that does not have OCIXML TypeCreateFromSrc Either use an earlier version of DBD.Oracle like 1.20 or 1.19 or update you Oracle client to the latest version of the instant client. can you post what the results of your Makefile.PL and your compile where. You might want to check that the what your Path setting is as well Kanhaiya Prasad wrote: Hello I've installed Perl 5.10 successfully and all other perl program running perfectly. But it's showing following problem when i'm trying to connect oracle Problem: 1. The procedure entry point OCIXML TypeCreateFromSrc could not be located in the dynamic link library OCI.dll. 2. install_driver(Oracle) failed: Can't load 'C:/Perl/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file: The specified procedure could not be found at C:/Perl/lib/DynaLoader.pm line 202 at (eval 4) line 3 Compilation failed in require at (level 4) line 3. Perhaps a required shared library or dll isn't installed where expected at dbi.pl line 3 See below mentioned coding from which I intended to connect Oracle (dbi.pl) use strict; use DBI; my $dbh = DBI-connect( 'dbi:Oracle:orcl','scott','tiger',)|| die Database connection not made: $DBI::errstr; $dbh-disconnect(); Thanks Kanhaiya Prasad Delhi
Re: Problem connecting to non-default db
Hi,
Thanks, use dbA works. It doesn't work as part of a do statement (i.e. $dbh-
do(use dbA)), but it looks like it's working when I prep and execute use
dbA using a statement handle.
I'm using DBD::Sybase v1.01, so I guess there's still an issue with DBI only
connecting to the default db. I've cc'd dbi-dev since they might like to know
about this bug.
Thanks and take care,
Bilal
Quoting Chuck Fox [EMAIL PROTECTED]:
Bilal,
Try just executing use dbA after the connection is made. Another
option is to directly reference the db in the query by using select *
from dbA.dbo.array. A table can be referenced as tableName or
ownerName.tableName or as databaseName.ownerName.tableName. Insofar as
the bug, try ugrading to the latest dbd, I believe that 1.01 was just
released. We are using 1.0 and the issue with the db disappeared
there. I think the fix was in the 0.94 release.
Chuck
[EMAIL PROTECTED] wrote:
Hi,
Do you mean replace dbname=dbA with dbname=dbB in my connect string?
I've tried that. Is there another way to switch the data source to
another db?
Is there any fix for this DBD::Sybase bug?
Thanks,
Bilal
On Thu, 11 Sep 2003, Chuck Fox wrote:
[EMAIL PROTECTED] wrote:
Hi,
Hello,
I'm trying to connect to two ms sqlserver 2000 databases with the same
schema
(let's call them
dbA and dbB) using the following code:
my $connect_string = dbi:Sybase:dbname=dbA:server=MyServer;
$connect_string .= ;host=192.168.0.2;port=1433;
my $dbh = DBI-connect($connect_string, $username, $userpass, {PrintError
=
0});
die Unable for connect to server $DBI::errstr
unless $dbh;
and in my freetds.conf I have:
[MyServer]
host = 192.168.0.2
port = 1433
tds version = 4.2
try domain login = no
try server login = yes
I have read access to both dbA and dbB. However if dbB is my default db
and I
specify dbA as the dbname (as in the example above), or vice versa, when
my
script executes the following:
Why not just use dbB or whichever is appropriate to the query ? I
seem to remember some bug in Sybase DBD that prevented it from
using/processing the database specified in the connect string.
$sth = $dbh-prepare(select count(*) from array);
die Unable for connect to server $DBI::errstr unless $sth;
if($sth-execute) {
while(my @dat = $sth-fetchrow) {
print @dat\n;
}
}
the data is retrieved from the default db rather than the one I specified
(btw,
yes, i know for sure that the select count(*) from array on both db's
should
return different numbers). So I think that DBI's only connecting to the
default db.
As well, the statment
print Data sources: . ($dbh-data_sources()) . \n $DBI::errstr\n;
prints out no data sources.
The DBD I'm using is DBD::Sybase running on the freetds library. My
script's
running on a linux box and the sqlserver 2000 db's are on a windows 2000
adv
server box.
So any ideas on how I may get around this problem? I would really
appreciate
any help.
Thanks,
Take care,
Bilal
HTH,
Chuck Fox
Principal DBA
America Online, INC
