in reply to Fetchrow_hashref behaves differently when >1 row in $sth?

Your sample code runs fine for me -- well, at least it did after I figured out I had to run it without the "drop table" line the first time... *grin*

Are you using a recent version of DBD::SQLite?

  • Comment on Re: Fetchrow_hashref behaves differently when >1 row in $sth?

Replies are listed 'Best First'.
Re: Re: Fetchrow_hashref behaves differently when >1 row in $sth?
by pboin (Deacon) on Apr 17, 2004 at 11:41 UTC
    As recent as CPAN has, which is 0.31. Just to confirm, are you telling me that you *don't* get the following on the second sql update: 
        <- prepare('UPDATE files SET uploadrc='x' WHERE locname='dat/19980
+820/ACCT3445'')= DBI::st=HASH(0x829e50c) at upman.pl line 30
    !! ERROR: 1 undef
    <- execute= undef at upman.pl line 32

    [download]
    Hmmm... I thought that posting 'working' broken code would prevent that. Thanks for taking the time to look though.
[reply]
[d/l]
      Just to confirm, are you telling me that you *don't* get the following on the second sql update: ... !! ERROR: 1 undef

      Correct, there's no "ERROR" in the output, attached below.

      Read more... (5 kB)
[reply]
[d/l]
      Since this sounds like a bug in your system, it sounds like time for a bug report to the author. In that bug report, the output of "perl -V" is likely to be helpful.

      Since the error is in the output of the database, odds are that the bug will have to get reported to the author of SQLite. For that it may be helpful to visit http://www.hwaci.com/sw/sqlite/ and see if you can generate the error without Perl in the mix. If you can then report it there directly instead.

      Yes, I know that all of this is a PITA to do. But having users be willing to go through the work of submitting good bug reports is part of what makes open source able to work. (And normally if you do this, the quality of the support that you get is quite impressive.)

[reply]

In Section Seekers of Perl Wisdom