In the original question I did put it was untested and showed the query as:

y $cards = $dbh->prepare("SELECT Card_idCard FROM CardList WHERE User_
+idUser = $user_number AND visible = 1 ORDER BY metric");
[download]

my $card;
while (($card) = $cards->fetchrow_array)
[download]

I haven't completely got my head around why

In while (my ($card) = $cards->fetchrow_array), the boolean condition being evaluated is the return value of the list assignment ()=..., and as per Assignment Operators, "a list assignment in scalar context returns the number of elements produced by the expression on the right hand side of the assignment."

However, like LanX, I can't reproduce this, and you'd have to show an SSCCE that does. Are you sure you didn't accidentally write fetchrow_arrayref instead? That method returns undef if no more rows remain - and as per the above, it's one value being assigned, so the return value of the list assignment is 1 (true). For fetchrow_arrayref, the correct loop condition is while (my $card = $cards->fetchrow_arrayref), since that's a scalar assignment and it'll return undef (false).

use warnings;
use strict;
use Data::Dumper;
use DBI;

my $dbh = DBI->connect("dbi:SQLite:dbname=:memory:", undef, undef,
    { RaiseError=>1, AutoCommit=>1 } );

$dbh->do(q{ CREATE TABLE foobar ( foo TEXT, bar TEXT ) });
my $in = $dbh->prepare(q{INSERT INTO foobar (foo,bar) VALUES (?,?)});
$in->execute('a','b');
$in->execute('c','d');

my $cards = $dbh->prepare('SELECT * FROM foobar');
$cards->execute;
while (my ($card) = $cards->fetchrow_array) {
# OR
#while (my $card = $cards->fetchrow_arrayref) {
# BUT NOT 
#while (my ($card) = $cards->fetchrow_arrayref) {
    print Dumper($card);
}
[download]

> while (my $card = $cards->fetchrow_arrayref), since that's a scalar assignment and it'll return undef (false).

Well it could have been designed to detect that it's called in list context and return an empty list when the table is exhausted.

Or at least throw an error.

But I have a strong deja-vu feeling right now, I think I said this before...

DBI.pm is one of the messier parts of Perl's eco system.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Are you sure you didn't accidentally write fetchrow_arrayref instead?

Sorry - you are quite correct. I am mixing up fetchrow_array with the behaviour of fetchrow_hashref. I had been bitten by converting some code described here -> Re^3: my $x or my ($x).

I have encountered similar problems before and I'm not sure either.
Perl has some complicated rules about "definedness" and creating "my" variables within looping statements.
I hope the Monks can further explain this seeming "weirdness".

As a suggestion, I most often use fetchall_arrayref.
Something like:


my $card_ref = $cards->fetchall_arrayref;
foreach my $card (@$card_ref)
{..}
[download]

This does expand the memory used by Perl to include the entire result set. But that is fine if the result set is "small" and the memory used for that result is recycled for further use by Perl. "Small" is a relative term. Nowadays, I would consider a 10,000 line result set as "small".

I always use refs as well. My first question at an API is if it can provide me with refs. Provided that the returned data will be processed locally and immediately

> However, when written as you suggest, it always returns true

That's hard to believe, it's a very common construct.

And a little test in the debugger doesn't show any endless loop.

 

  DB<2> while ( my ($x) = () ) {die $x}

  DB<3>
[download]

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Sorry - I was confusing the error I detailed in this post -> Re^3: my $x or my ($x)

Of course you are right about it being a common construct and, as soon as I tried to reproduce the problem it became obvious I was getting rather muddled.