I am a bit flummoxed as to how you get -1 as the result.
-1 is a legal return value for $sth->execute(). Quoting the DBI documentation:
For a non-SELECT statement, execute returns the number of rows affected, if known. If no rows were affected, then execute returns "0E0", which Perl will treat as 0 but will regard as true. Note that it is not an error for no rows to be affected by a statement. If the number of rows affected is not known, then execute returns -1.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
I learned something: If the number of rows affected is not known, then execute() returns -1. Usually with an SQL statement (UPDATE or whatever), the number of rows affected will be known. This is different because of the execution of a stored procedure.
In my experience, it is relatively easy to translate working command line SQL code into Perl code. I would like to see the command line SQL statements that are claimed to "work".
Update: As I wrote earlier, I've never seen -1 (unknown number of rows affected). A normal SQL UPDATE or INSERT knows that number. The DBI can return the string value of 0EO which evaluates to "true" in a scalar context but is numerically zero in a math context or a number representing the number of rows affected. As I learned, in this situation, a negative number could be returned.
I HIGHLY recommend that you work from the SQL command line to get a valid result. Once you have that, we can make Perl do the same thing. Once we are past that, other optimization can be done about error conditions. Start from known working SQL code. Make Perl do the same thing that you know works. Then go from there.
| [reply] |
