On Dec 1, 2008, at 9:54 AM, Larry W. Virden wrote:
I inherited some perl code that mostly works, but which I've a couple
questions about what it is doing.
Skipping miscellaneous comments, etc. the code sets some variables
from a file, sets its oracle environment, and then does the following:
$oraProdDBH = DBI->connect("dbi:Oracle:", $user_name, $password)
or die "Failed to connect to $DBI:errstr\n";
$oraProdDBH->{RaiseError} = 1;
$oraProdDBH->{AutoCommit} = 0;
$oraProdDBH->{LongReadLen}=4000;
$getMatchRec = $oraProdDBH->prepare
(q{
SELECT sec_person_id, unix_uid FROM csi_core
WHERE sec_person_id != 0 GROUP BY unix_uid, sec_person_id
HAVING COUNT(sec_person_id) > 1
});
$getMatchRec->execute()
or die "Couldn't fetch records from CSI_CORE";
if ($oraProdDBH->rows != 0)
{
and proceeds to do some stuff.
What does that rows member of the oraProdDBH handle represent? When I
print it out, it doesn't appear to be the number of rows selected. In
fact, right now, it has a value of -1.
Is there a meaning for it? From reading the docs, it seems as if
getting past that die statement should mean that the statement
actually executed (regardless of whether it returned any rows).
The docs are not unclear: rows is not reliable for selects. So
don't use it for them.
"
Returns the number of rows affected by the last row
affecting
command, or -1 if the number of rows is not known or not
available.
Generally, you can only rely on a row count after a
non-"SELECT"
"execute" (for some specific operations like "UPDATE" and
"DELETE"), or after fetching all the rows of a "SELECT"
statement.
For "SELECT" statements, it is generally not possible to
know how
many rows will be returned except by fetching them all.
Some
drivers will return the number of rows the application has
fetched
so far, but others may return -1 until all rows have been
fetched.
So use of the "rows" method or $DBI::rows with "SELECT"
statements
is not recommended.
"
