Re: fetchrow_hashref helpful hint.

You could also use NVL (NAME, 'NONE') instead of the DECODE to achieve the same result. However, the column alias is still required. Steve On Tuesday 02 July 2002 15:46, Stacy Mader wrote: > Hello all, > > I ran into a little problem using fetchrow_hashref: > > use strict; > > $sth = $dbh->pre

fetchrow_hashref helpful hint.

Hello all, I ran into a little problem using fetchrow_hashref: use strict; $sth = $dbh->prepare(qq{ SELECT ID, DECODE(NAME,NULL,'NONE',NAME) FROM $table}); $sth->execute(); my(%hash) = %{$sth->fetchrow_hashref('NAME_lc')}; $sth->finish;

Re: sth->cancel

- Original Message - From: "Tim Bunce" <[EMAIL PROTECTED]> > Can you point me to a reference that shows close() doing exactly > what finish() does? I can't say for sure its exactly the same, but it does remind me of Informix where you might say: open some_cursor using some_bind_variabl

Re: CLOB insert with bind_param problem

Stacy, tom kyte's definitive oracle book references unwise java programmers who adopt the max(id+1) plan. it is not scalable, requires locking, forces full scans of the entire id column (if it is indexed) or full table scans if it is not. I am sure I am missing many of the myriad reasons he dis

Re: CLOB insert with bind_param problem

I've tried sequences, but if there is an error, the sequence cannot be rolled back in any easy way and there are "gaps" in the database :( Stacy. > not related to your problem, but > use a sequence. > the max(num+1) is a bad idea. > --- Stacy Mader <[EMAIL PROTECTED]> wrote: > > > > Hi

Re: A question

On Mon, 01 Jul 2002 11:32:21 -0400 Sean Spillane <[EMAIL PROTECTED]> wrote: > I am using a really ancient version of (PERL 5.00404) and can't upgrade. > I was wondering where I might find an old version of the DBI package > that will build against this PERL? I have some old source archives for

Re: sth->cancel

On Mon, 1 Jul 2002 21:34:50 +0100 Tim Bunce <[EMAIL PROTECTED]> wrote: > On Mon, Jul 01, 2002 at 02:51:11PM +0200, Bart Lateur wrote: > > On Mon, 1 Jul 2002 12:18:31 +0100, Tim Bunce wrote: > > > > >> >I'll probably rename finish() to something like > discard_unfetched_rows(). > > >> >(Keeping a

Re: sth->cancel

The one I'm most familiar with is the JDBC spec, specifically ResultSet.close() (and I guess Statement.close() is similar as well). And of course, one could argue that, after execute() completes, $sth is just a cursor handle, and "CLOSE " has been the standard SQL way to close a cur

database lock timeouts in AuthDBI

Apologies if this is a FAQ, but can anybody tell me if there is support for database lock timeouts in AuthDBI? If not, we are probably going to hack them in. We have had a few instances of our Ingres database server crashing because of a buildup of database locks. Thanks. -- -- Bill Edward

Re: sth->cancel

On Mon, Jul 01, 2002 at 02:51:11PM +0200, Bart Lateur wrote: > On Mon, 1 Jul 2002 12:18:31 +0100, Tim Bunce wrote: > > >> >I'll probably rename finish() to something like discard_unfetched_rows(). > >> >(Keeping an alias for old code of course.) > >> > >> I guess I got the idea from this sentenc

Re: sth->cancel

Can you point me to a reference that shows close() doing exactly what finish() does? Tim. On Mon, Jul 01, 2002 at 07:28:15AM -0700, Dean Arnold wrote: > Perhaps just $sth->close() is sufficient ? This would mimic > most other API's syntax... > > Dean Arnold > > > > > > > > >I'll probably renam

Re: Select statement as variable

On Mon, Jul 01, 2002 at 01:51:44PM -0400, Jennifer Newberry wrote: > DBD::Oracle::db prepare failed: ORA-00900: invalid SQL statement (DBD: > error possibly near <*> indicator at char 1 in '<*>'Select a.prty, > a.mess, a.cdat, a.suno, a.alrt from alerts a where a.dnst = 2 order by > a.prty, a.cda

Errors with ORACLE 8.0.5

I have installed DBI-1.18 and ORACLE-DBD-1.07 on several UNIX hosts running ORACLE 8.0.6 with no problem. I get errors on a host with ORACLE 8.0.5 The Perl -v output is 5.005_02 on both hosts On the ORACLE 8.0.5 host I get the following errors when running make test PERL_DL_NONLAZY=1

mySQl keeps dying when using perl apps w/ DBD/DBI interface

I'm using a web-based application written in perl 5.6.1 on a Linux 7.2 server with mySQL 3.23.49 and Apache 1.3.22. Whenever my interface makes a call to the mySQL backend whatever tables it touches have one of two (or both) problems afterwards that can be seen with the musql command tool: 1. c

Select statement as variable

I am trying to pass the select statement as a variable, depending on which type of access someone has, but I get an error: DBD::Oracle::db prepare failed: ORA-00900: invalid SQL statement (DBD: error possibly near <*> indicator at char 1 in '<*>'Select a.prty, a.mess, a.cdat, a.suno, a.alrt f

Re: Bind problem in a loop (with Sybase?)

On Mon, 2002-07-01 at 05:15, HOPKINSON, Jonathan, FM GR wrote: > I'm having problems with a statement handle running Perl 5.6 with Sybase. In > short the loop below works first time through then falls over second time > round with the following messages > > ct_param() failed! at profile_handler l

FW: DBI make fails on hp-ux

Hello As per README instructions when looking for help. This problem happens with 1.28 and 1.24 DBI. Any help welcome. Thanks Richard Script started on Mon Jul 1 17:02:25 2002 # pwd /.cpan/build/DBI-1.24 # perl Makefile.PL *** You are using a perl with experimental threading enabled! *** Y

A question

I am using a really ancient version of (PERL 5.00404) and can't upgrade. I was wondering where I might find an old version of the DBI package that will build against this PERL? -- Sean Spillane [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ever try to shoot a frozen c

Re: CGI.pm & DBI

On Mon, 1 Jul 2002 08:54:50 -0700 (PDT) Will <[EMAIL PROTECTED]> wrote: > I double checked the conversation in my ICQ history, > and I had one little glitch... > > Err... It wasnt CGI.pm, but mod_perl he was warning > me about... Sorry for the mixup... > > Anyway, I still dont get why one wou

Re: CGI.pm & DBI

I double checked the conversation in my ICQ history, and I had one little glitch... Err... It wasnt CGI.pm, but mod_perl he was warning me about... Sorry for the mixup... Anyway, I still dont get why one would have to use DBI's do() commands instead of the regular connect(), prepare(), execute

Re: sth->cancel

Perhaps just $sth->close() is sufficient ? This would mimic most other API's syntax... Dean Arnold > > > > > >I'll probably rename finish() to something like discard_unfetched_rows(). > > >(Keeping an alias for old code of course.) > > > > I guess I got the idea from this sentence in perldoc DBI

Getting a non fatal error after Connect to Oracle

HI, I am running perl 5.00503 on a SCO UnixWare 7.1.1 box with Oracle 8.16 installed. I am using DBI version 1.21 and DBD::Oracle Version 1.12 to connect to the database. What I am trying to do is to write a piece of Java which will run the Perl script I am writing on the server. The Pe

Re: sth->cancel

On Mon, 1 Jul 2002 12:18:31 +0100, Tim Bunce wrote: >> >I'll probably rename finish() to something like discard_unfetched_rows(). >> >(Keeping an alias for old code of course.) >> >> I guess I got the idea from this sentence in perldoc DBI: >> >> The `finish' method should have been cal

Bind problem in a loop (with Sybase?)

I'm having problems with a statement handle running Perl 5.6 with Sybase. In short the loop below works first time through then falls over second time round with the following messages ct_param() failed! at profile_handler line 952. ct_param() failed! at profile_handler line 953. ct_param() faile

Re: sth->cancel

On Sun, Jun 30, 2002 at 08:30:31PM -0500, Paul DuBois wrote: > At 23:32 +0100 6/30/02, Tim Bunce wrote: > >On Sun, Jun 30, 2002 at 10:43:19AM -0700, Michael A Chase wrote: > >> On Sun, 30 Jun 2002 11:48:49 -0500 Paul DuBois <[EMAIL PROTECTED]> wrote: > >> > >> > At 16:23 +0100 6/30/02, Tim Bunce

Re: CLOB insert with bind_param problem

not related to your problem, but use a sequence. the max(num+1) is a bad idea. Job --- Stacy Mader <[EMAIL PROTECTED]> wrote: > > Hi all. > > Using DBI 1.28 and DBD::Oracle 1.12 compiled against > Oracle 8.1.7, > I have the following: > > use strict; > use DBI; > > $text = "This is a test.\n"