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}

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.

There are arguments to be made for and against this. If a method is documented to return a scalar, then you'd expect to be able to do my %data = ( foo => $sth->fetchrow_arrayref, bar => 123 );, if it suddenly returns the empty list that'd be a problem.

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).

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

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

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

I could be wrong about this, but in my testing, asking for an array_ref like above, causes the entire result set to be copied into Perl memory. If you undefine the array_ref or assign it another value, Perl can reuse that memory. I haven't benchmarked this, but I'm sure that other Monks have: I suspect that getting an array_ref is faster than going row by row with the exception of an enormous result set.

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]

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.