in reply to MSSQL and Perl - heavy load

In addition to what bv explained, the $sth->fetchrow may also fail. From the docs (emphasis added):

If there are no more rows or if an error occurs, then fetchrow_array returns an empty list. You should check $sth->err afterwards (or use the RaiseError attribute) to discover if the empty list returned was due to an error.

Replies are listed 'Best First'.
Re^2: MSSQL and Perl - heavy load
by taomanjay (Novice) on Jan 11, 2010 at 18:46 UTC
    This sounds like something that might work for me. Does that return an int? So, could I do this: 
            @lastsale = $sth->fetchrow;

        if ( $sth->err ){
                exit 1;
                }

    [download]
    Not that I would do it exactly like that, but should that work?
[reply]
[d/l]

      Yes, as I read the docs, that should work fine (though it might be more informative to also print the $sth->errstr instead of simply doing exit 1).  As you're simply testing for truth, it does not matter whether ->err returns an integer or not (which doesn't seem to be guaranteed).

      In general, when unconditionally reading/testing error variables or methods, it's good to check the docs, because in some cases, their value is invalid unless an error did in fact occur — think of $!. In this particular case though, this is not a problem, as the docs explicitly state "the DBI resets $h->err to undef before almost all DBI method calls" (the "almost all" refers to methods irrelevant here).

[reply]
[d/l]
[select]
        Yes, I'll be logging the contents of $sth->errstr, and I'll also disconnect the db connection before exiting. Thanks almut, and everyone else who posted!
[reply]

In Section Seekers of Perl Wisdom