DBI and Signals

2001-11-12 Thread Mark Riehl

All - I'm running under Win2k.  I know that signals aren't totally supported
under Windows, but I've got some questions related to DBI.

In the following script, I can't seem to catch the SIG INT after a
connection to the database is made (even w/o making any queries).  Without
the connect calls, I can catch a SIG INT without a problem.

Right now, the only way to stop this script is to use the task manager and
kill it - is there a better way to do this?

Thanks,
Mark

###
#!perl -w

use strict;
use diagnostics;
use DBI;

my $quit = 0;
$SIG{INT} = \catch_int;

while (!$quit) {
  print in while()\n;

  # Comment out these two lines and it works fine.  
  ##
  my $result = query_db();
  print $result;
  ##

  my $i = 0;
  for ($i = 0; $i  10; $i++) {
sleep (1);
print . ;
  }
}

sub query_db {
   # Build the database connection string.
  my $dbstring = DBI:mysql:database01:127.0.0.1:3306;

  # Connect to the database.
  my $dbh = DBI-connect($dbstring,user,password)
or die Can't connect to mysql on 127.0.0.1: $DBI::errstr\n;

  # Assume result from the db is named result.
  my $result = Test;

  print Disconnecting \$dbh\n;
  $dbh-disconnect()
or warn Disconnection failed: $DBI::errstr\n;

  return ($result);
}

sub catch_int { 
  my $sig = shift;

  print Caught $sig\n;
  $quit++;
}


--
Mark Riehl
Agile Communications, Inc.
Email: [EMAIL PROTECTED]
Business: (732) 528-9305
Fax: (732) 528-9308
Cell: (732) 996-7630




Perl Pg

2001-11-12 Thread Michael Wray

I know this is off-topic..but I am just looking for a place with good documentation 
for Perl-Pg.  Since for my purposes performance is key and the Pg module can give it 
to me..but the documentation for it is poor at best, and I am not a C-programmer and 
am an amateur at Perl at best so I need more examples of using the Pg module




Re: Perl Pg

2001-11-12 Thread Hardy Merrill

By Pg, do you mean PostgreSQL database?  The only interface that
I'm aware of for Perl to PostgreSQL is through DBI and DBD::Pg.  In
terms of documentation for PostgreSQL, I'd start with the Postgresql
home page at

   http://www.postgresql.org

or go to google(www.google.com) and search for postgresql.

HTH.

-- 
Hardy Merrill
Mission Critical Linux, Inc.
http://www.missioncriticallinux.com

Michael Wray [[EMAIL PROTECTED]] wrote:
 I know this is off-topic..but I am just looking for a place with good documentation 
for Perl-Pg.  Since for my purposes performance is key and the Pg module can give it 
to me..but the documentation for it is poor at best, and I am not a C-programmer and 
am an amateur at Perl at best so I need more examples of using the Pg module 



Re: Perl Pg

2001-11-12 Thread Rudy Lippan

On Mon, 12 Nov 2001, Hardy Merrill wrote:

 By Pg, do you mean PostgreSQL database?  The only interface that
 I'm aware of for Perl to PostgreSQL is through DBI and DBD::Pg.  In
 terms of documentation for PostgreSQL, I'd start with the Postgresql
 home page at

There is(was?) a Pg interface to perl: 
http://search.cpan.org/doc/MERGL/pgsql_perl5-1.9.0/Pg.pm

And then there was an attempt to write a pure-perl interface for Postgres.
I don't think it ever got very far, and I don't remember the name of the
pagkage.

DBI/DBD::Pg is the way to go.  Performance is very good, and DBI makes it
easier for you to port your code to other databases.


Rudy






Re: Get information about login from database handle

2001-11-12 Thread Bernhard Schmalhofer

Garry Taylor wrote:
 
 Sterin, Ilya wrote:
 
 Why would you want to do that.  Don't you already have that info when
 logging a user in?
 
 Not necessarily, especially if you are in a function that is passed a
 $dbh to work with, and you've no control over how the programmer makes
 the connection in the first place.  You might not even know which type of
 database server it is connected to, though that is less usual.
 
 Many (well, at least some) commercial databases provide mechanisms such
 as SELECT USERNAME or CURRENT_USER or some similar construct to allow you
 to identify the current user.
 
   That's pretty much why I need to do this, unfortunatly I am using
 mySQL not Oracle.
   Anyway, if it's not possible, I'll just find a workaround.
MySQL is sometimes better than expected.
You can try  
select User(), Database() and SHOW variables;

CU, Bernhard 
 
 Thanks
 
 Garry

-- 
*
Bernhard Schmalhofer
Software Engineer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel:+49 89 89 55 74 - 39
Fax:+49 89 89 55 74 - 25
mailto:[EMAIL PROTECTED]
http://www.biomax.de
*



Re: Perl Pg

2001-11-12 Thread Brett W. McCoy

On Mon, 12 Nov 2001, Rudy Lippan wrote:

 There is(was?) a Pg interface to perl:
 http://search.cpan.org/doc/MERGL/pgsql_perl5-1.9.0/Pg.pm

Yes, it's basically just a wrapper for libpq and basically has the same
set of functions/methods.

-- Brett
  http://www.chapelperilous.net/

To err is human, to moo bovine.




Stored Procedure Array

2001-11-12 Thread Benoit Rey

Hello,

I have a stored procedure wich has an array of values as entry parameter.

Is it possible with DBI to bind an array  @tab ?


For example :

$sti=$dbi-prepare(BEGIN .$PackageNameOracle..myProcedure (:1,:2,:3);
END;);

$sti-bind_param(1, $var1);
$sti-bind_param(2, @tab);  ???
$sti-bind_param_inout(3, \$var2, 4);

$sti-execute;


If it's possible how to do it?

Thanks.




Re: Stored Procedure Array

2001-11-12 Thread Ronald J Kimball

On Mon, Nov 12, 2001 at 06:50:14PM +0100, Benoit Rey wrote:
 I have a stored procedure wich has an array of values as entry parameter.
 
 Is it possible with DBI to bind an array  @tab ?
 
 
 For example :
 
 $sti=$dbi-prepare(BEGIN .$PackageNameOracle..myProcedure (:1,:2,:3);
 END;);
 
 $sti-bind_param(1, $var1);
 $sti-bind_param(2, @tab);  ???
 $sti-bind_param_inout(3, \$var2, 4);
 
 $sti-execute;
 
 If it's possible how to do it?

It is not possible.  You have to bind each placeholder's value separately.

You could do something like this, to avoid repeated code:

$p = 0;
$sti-bind_param(++$p, $var1);
foreach (@tab) {
  $sti-bind_param(++$p, $_);
}

Of course, you'll have to make sure @tab holds the correct number of
values.


Ronald



Re: Stored Procedure Array

2001-11-12 Thread Dean Arnold

 On Mon, Nov 12, 2001 at 06:50:14PM +0100, Benoit Rey wrote:
  I have a stored procedure wich has an array of values as entry parameter.
  
  Is it possible with DBI to bind an array  @tab ?
  
  
  For example :
  
  $sti=$dbi-prepare(BEGIN .$PackageNameOracle..myProcedure (:1,:2,:3);
  END;);
  
  $sti-bind_param(1, $var1);
  $sti-bind_param(2, @tab);  ???
  $sti-bind_param_inout(3, \$var2, 4);
  
  $sti-execute;
  
  If it's possible how to do it?
 
 It is not possible.  You have to bind each placeholder's value separately.
 
 You could do something like this, to avoid repeated code:
 
 $p = 0;
 $sti-bind_param(++$p, $var1);
 foreach (@tab) {
   $sti-bind_param(++$p, $_);
 }
 
 Of course, you'll have to make sure @tab holds the correct number of
 values.
 
 
 Ronald

I'm not certain that addresses Mssr. Rey's issue. He only has 3 params,
the 2nd of which is an array. However, I'm afraid the response to his inquiry
remains the same: at present this is not possible.

Since I've recently seen this issue popping up here again, as well as having been
directly contacted by a few folks, I'll drag this dead horse out again:

Are we any closer to array binding support ? Is there anything else I can
do (aside from my DBD::ODBC hacks, and occasional lobbying) to
move this issue forward ? I wish I had resources to sponsor the activity,
but alas I'm bootstrapping my own efforts right now.

Would it be considered a gross violation of net ettiquette for me to repackage
my DBD::ODBC hack as, say, DBD::ODBCAry, and post it to CPAN ?
I'd rather not generate a fork unneccesarily, but it is approaching a year
since I first reported my results, and it would be a one-shot posting
(other than serious bug fixes), to be obsoleted once DBD::ODBC
provides this capability.
While I can't assure Benoit that my hack will address his particular
issue, it should address more general application issues I've seen
raised here over the past few months (for those using DBD::ODBC,
of course).

Regards,
Dean Arnold




DBD::Proxyserver/Win32/Threads?

2001-11-12 Thread turnerjw2

Has anyone gotten the DBD::Proxy server to run on Windows-NT with 
threads?  I am using ActivePerl, v. 5.6 and everything works fine with 
--mode=single, but when trying to start up with --mode=threads, I get:

Can't call method tid on an undefined value at c:/Perl/site/lib/Net/Daemon/Log.pm 
line 75

The server starts up running as Administrator.  What I want is to allow 
more that 1 user to connect to the database via the DBD::Proxy at the 
same time.


Thanks in advance,

Jim Turner
[EMAIL PROTECTED]



__
Your favorite stores, helpful shopping tools and great gift ideas. Experience the 
convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/




Re: DBD::Proxyserver/Win32/Threads?

2001-11-12 Thread Jochen Wiedmann

Quoting [EMAIL PROTECTED]:

 Can't call method tid on an undefined value at
 c:/Perl/site/lib/Net/Daemon/Log.pm line 75

Strange, Thread-self seems to return undef under ActivePerl ...

Well, please try Net::Daemon 0.36, which I have uploaded to
CPAN some minutes ago. That problem should be handled properly
now. (Which doesn't necessarily mean that everything works. :-)


Thanks,

Jochen



how to get more specific DBD::Oracle errors

2001-11-12 Thread Jonathan Swartz

With DBI 1.20 and DBD::Oracle 1.12 and ShowErrorStatement set, an invalid
column name error looks like:

error preparing query: ORA-00904: invalid column name (DBD ERROR:
OCIStmtExecute/Describe) (select foo from walls where wall_id = 1)

Needless to say this is a frustratingly unspecific error, especially with a
table of many columns.

I have to believe there is a way to get an error with the specific column
name, or at least with the '*' position marker given by sqlplus. Can anyone
help?

TIA
Jon



RE: merant / ODBC - DBI/DBD

2001-11-12 Thread Mitsuda, Alex

You can do this using DBD::Sybase Library and DBI as long as the SQLServer7
has most uptodate patch, without having to use Merant/ODBC solution. Though
I'm not sure how the DBD::Sybase install will go without actually having
Sybase on the box...

-Original Message-
From: Meng Yoke [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 11, 2001 10:18 AM
To: [EMAIL PROTECTED]
Subject: merant / ODBC - DBI/DBD


Hi,

MERANT / DBI/DBD / ODBC / Solaris 8 - SQL7/NT

I need to use write perl (possibly DBI/DBD) in Solaris
to connect to SQL7 on NT machine.

Does anyone done such script before?
I need to know of problem that I may be facing and
possibly your-comment?

Thanks.

- Yoke


=
===
   Yoke Meng Keong
   Email : [EMAIL PROTECTED] 
   eFax  : (253) 669-6578 (US)
===

__
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com


 

This message contains confidential information and is intended only for the
individual named.  If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.  Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. 

E-mail transmission cannot be guaranteed to be secure or error-free.  The
sender therefore does not accept liability for any errors or omissions in
the contents of this message that arise as a result of e-mail transmission.
This message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments. 

All e-mails at Neuberger Berman are, in accordance with Firm policy, to be
used for Neuberger Berman business purposes only.  E-mails sent from or to
the Firm are subject to being reviewed by the Firm in accordance with the
Firm's procedure for the review of correspondence.



Re: merant / ODBC - DBI/DBD

2001-11-12 Thread Keith A. Clay

Mitsuda, Alex wrote:

You can do this using DBD::Sybase Library and DBI as long as the SQLServer7
has most uptodate patch, without having to use Merant/ODBC solution. Though
I'm not sure how the DBD::Sybase install will go without actually having
Sybase on the box...

It works great as long as you have the freetds (I'm using 0.51) and the 
0.91 version of DBD::Sybase.  The newest version will NOT work.  Once 
you set up your interfaces file in freetds and everything is compiled 
and installed, it works like a charm.

keith

-- 
-
Keith Clay, [EMAIL PROTECTED]
Lead Programmer, Web Integration and Programming
286 Adams Center for Teaching Excellence
Abilene Christian University
Abilene, TX 79699
(915) 674-2187
(915) 674-2834
-






whitespace becomes NULL in bind params?

2001-11-12 Thread Jonathan Swartz

Using my version of DBD::Oracle, all-whitespace bind values seem to become
NULL:

# The following inserts '   '
my $sth = $db-prepare(insert into test (a) values ('   '));
$sth-execute();

# The following inserts NULL
my $sth = $db-prepare(insert into test (a) values (?));
$sth-execute('   ');

Cannot find anything about this in the docs or FAQ. Wondering if it's a bug.
Any help appreciated.

DBI 1.20, DBD::Oracle 1.12, Oracle 8.1.6, Perl 5.6.1

TIA
Jon



Re: Perl Pg

2001-11-12 Thread Michael Wray

Thanks for the suggestions, but here's my 2 cents on DBI/DBD::Pg:.

I would LOVE to use DBD::Pg...I have written a lot of code using 
DBD::Pg...however...unless there is a Monumental Performance increase between DBD::Pg 
that was out with DBI-1.16, and the current version..I don't think  I can consider 
this...That and right now I think I am looking at less coding for libpq as most of the 
routines will port straight across from PHP. (Note...I said amateur not NOVICE..)

If I were ONLY doing Report type queries and no UPDATES..then DBI would be fine...

I have already tried this project using DBD::Pg...performance from DBD::Pg suckedI 
am already using the libpq routines in PHP (written by another programmer.) with 
amazing results...from other reports I have seen...moving away from apache and going 
pure perl with the Pg module will give me blazing performance.  (Yes..PosgtGres)...I 
have no need of porting my code to another database...this is a proprietary product 
and will be maintained and released by this company for quite awhileI need 
speed..not portability...The way they are being used in PHP does not match my needs 
though and I need info on Error response codes from libpq.

DBD adds an extra layer to the programming that I am trying to cut outthat extra 
layer cuts way into performance...


I can manually replicate my database faster by hand than by any of the available 
methods in DBD::Pg...and in fact have done so...(And that was a LONG night...)


My end goal:

Client-Perl-libpq (Pg)-Postgres,
which sits now as:
Client-Apache-Php-libpq-PostGres.
will move to
Client-Apache-mod_perl-libpq-Postgres...then I will drop Apache...I don't need a 
full fledged WebServer for what I am doing...just a TCP server listening on the same 
port to handle DB queries in the form of a URL request...
*** REPLY SEPARATOR  ***

On 11/12/01 at 11:51 AM Rudy Lippan wrote:

On Mon, 12 Nov 2001, Hardy Merrill wrote:

 By Pg, do you mean PostgreSQL database?  The only interface that
 I'm aware of for Perl to PostgreSQL is through DBI and DBD::Pg.  In
 terms of documentation for PostgreSQL, I'd start with the Postgresql
 home page at

There is(was?) a Pg interface to perl:
http://search.cpan.org/doc/MERGL/pgsql_perl5-1.9.0/Pg.pm

And then there was an attempt to write a pure-perl interface for Postgres.
I don't think it ever got very far, and I don't remember the name of the
pagkage.

DBI/DBD::Pg is the way to go.  Performance is very good, and DBI makes it
easier for you to port your code to other databases.


Rudy

** 2K **




Re: Perl Pg

2001-11-12 Thread Alex Pilosov

I think you are doing something wrong. DBD::Pg is fast-to-unnoticeable.

I bet that with PHP you do your operations within one transaction (do an
explicit BEGIN or whatever way in PHP you start a transaction), whereas in
perl, you don't do $dbh-{AutoCommit}=0;

The best way to kill postgres' performance is to put each statement in its
own transaction (default, AutoCommit=1). 

If you post your source code, I might be able to help you out.

-alex

On Mon, 12 Nov 2001, Michael Wray wrote:

 Thanks for the suggestions, but here's my 2 cents on DBI/DBD::Pg:.
 
 I would LOVE to use DBD::Pg...I have written a lot of code using
 DBD::Pg...however...unless there is a Monumental Performance increase
 between DBD::Pg that was out with DBI-1.16, and the current version..I
 don't think I can consider this...That and right now I think I am
 looking at less coding for libpq as most of the routines will port
 straight across from PHP. (Note...I said amateur not NOVICE..)
 
 If I were ONLY doing Report type queries and no UPDATES..then DBI
 would be fine...
 
 I have already tried this project using DBD::Pg...performance from
 DBD::Pg suckedI am already using the libpq routines in PHP
 (written by another programmer.) with amazing results...from other
 reports I have seen...moving away from apache and going pure perl with
 the Pg module will give me blazing performance.  (Yes..PosgtGres)...I
 have no need of porting my code to another database...this is a
 proprietary product and will be maintained and released by this
 company for quite awhileI need speed..not portability...The way
 they are being used in PHP does not match my needs though and I need
 info on Error response codes from libpq.
 
 DBD adds an extra layer to the programming that I am trying to cut
 outthat extra layer cuts way into performance...
 
 
 I can manually replicate my database faster by hand than by any of the
 available methods in DBD::Pg...and in fact have done so...(And that
 was a LONG night...)
 
 
 My end goal:
 
 Client-Perl-libpq (Pg)-Postgres,
 which sits now as:
 Client-Apache-Php-libpq-PostGres.
 will move to
 Client-Apache-mod_perl-libpq-Postgres...then I will drop Apache...I don't need a 
full fledged WebServer for what I am doing...just a TCP server listening on the same 
port to handle DB queries in the form of a URL request...
 *** REPLY SEPARATOR  ***
 
 On 11/12/01 at 11:51 AM Rudy Lippan wrote:
 
 On Mon, 12 Nov 2001, Hardy Merrill wrote:
 
  By Pg, do you mean PostgreSQL database?  The only interface that
  I'm aware of for Perl to PostgreSQL is through DBI and DBD::Pg.  In
  terms of documentation for PostgreSQL, I'd start with the Postgresql
  home page at
 
 There is(was?) a Pg interface to perl: 
 http://search.cpan.org/doc/MERGL/pgsql_perl5-1.9.0/Pg.pm
 
 And then there was an attempt to write a pure-perl interface for Postgres.
 I don't think it ever got very far, and I don't remember the name of the
 pagkage.
 
 DBI/DBD::Pg is the way to go.  Performance is very good, and DBI makes it
 easier for you to port your code to other databases.
 
 
 Rudy
 
 ** 2K **