On Thu, Sep 12, 2002 at 10:12:29PM -0700, Jonathan Leffler wrote:
Tim Bunce wrote:
On Tue, Sep 10, 2002 at 01:49:35PM +0200, Roger Perttu wrote:
Tim Bunce wrote:
It has to as it's the standard way to check. The DBI docs specifically
say Non-CSELECT statements will have CNUM_OF_FIELDS == 0.
Tim Bunce wrote:
On Tue, Sep 10, 2002 at 01:49:35PM +0200, Roger Perttu wrote:
Tim Bunce wrote:
It has to as it's the standard way to check. The DBI docs specifically
say Non-CSELECT statements will have CNUM_OF_FIELDS == 0.
The pod is a bit unclear about NUM_OF_FIELDS. I know that it returns
Tim Bunce wrote:
On Tue, Sep 10, 2002 at 01:49:35PM +0200, Roger Perttu wrote:
Tim Bunce wrote:
On Wed, Sep 04, 2002 at 09:58:35AM -0500, Paul DuBois wrote:
At 9:50 -0500 9/4/02, David Dooling wrote:
For security reasons, wouldn't you want to know what statements
On Wed, Sep 04, 2002 at 09:58:35AM -0500, Paul DuBois wrote:
At 9:50 -0500 9/4/02, David Dooling wrote:
For security reasons, wouldn't you want to know what statements are
non-select _before_ you execute?
If you only care about after, how about something like this:
$sth-execute;
Bodo Eing wrote:
Roger Perttu wrote:
Hi everyone,
I have a problem with DBI. If I have no control of the SQL statement
being run, how do I know if it's safe to call fetchrow_hashref()?
my $sth = $dbh-prepare($someUnknownStatement);
$sth-execute();
# Safe to call fetchrow_hashref()?
on Wed, 04 Sep 2002 12:27:23 GMT, [EMAIL PROTECTED] (Roger
Perttu) wrote:
I have absolutely no control of the query.
So a simple 'DROP DATABASE' would also be acceptable ;-)
You can always write your own error handler.
Search
perldoc DBI
for 'HandleError'
--
felix
On Wed, Sep 04, 2002 at 02:27:23PM +0200, Roger Perttu wrote:
No, your suggestion won't work for me. I have absolutely no control of
the query. Stored procedures with multiple or no result sets will be
common. If I chose to use eval it will be rather painful to use
sth-trace() because of
Ronald J Kimball wrote:
On Wed, Sep 04, 2002 at 02:27:23PM +0200, Roger Perttu wrote:
No, your suggestion won't work for me. I have absolutely no control of
the query. Stored procedures with multiple or no result sets will be
common. If I chose to use eval it will be rather painful to use
For security reasons, wouldn't you want to know what statements are
non-select _before_ you execute?
If you only care about after, how about something like this:
$sth-execute;
my row = $sth-fetchrow_array;
if (row) { # results }
elsif (!$sth-errstr) { # now rows }
else {
At 9:50 -0500 9/4/02, David Dooling wrote:
For security reasons, wouldn't you want to know what statements are
non-select _before_ you execute?
If you only care about after, how about something like this:
$sth-execute;
my row = $sth-fetchrow_array;
if (row) { # results }
Felix Geerinckx wrote:
on Wed, 04 Sep 2002 12:27:23 GMT, [EMAIL PROTECTED] (Roger
Perttu) wrote:
I have absolutely no control of the query.
So a simple 'DROP DATABASE' would also be acceptable ;-)
Yes, The user might want to copy data from a production database to a
reporting
David Dooling wrote:
For security reasons, wouldn't you want to know what statements are
non-select _before_ you execute?
If you only care about after, how about something like this:
$sth-execute;
my row = $sth-fetchrow_array;
if (row) { # results }
elsif (!$sth-errstr) { # now
On Wed, Sep 04, 2002 at 05:47:19PM +0200, Roger Perttu wrote:
David Dooling wrote:
http://xsql.sourceforge.net/
Hmm, I've got this great invention, it's called the wheel :-)
To what wheel, specifically, are you referring? Does it have an
implementation in Perl? Does it have an free
13 matches
Mail list logo
