in reply to DBI, rows, and do

Thanks for the help, but still no luck. One thing I didn't make clear was that both the subs remove and get are in a module seperate of the main one. Remove is called externally and unless it returns true, the main script reacts. The row at the end of that sub makes sure that unless $rows>0 it returns undef and causes the external script to fail (unless I made a drastic error there, although the same script works fine with the 10 other calls to DBI).

Before I came here I had checked (ie. got proof of) as much as I could. $rows is definitely 1, $dat1 is the id I need and the exact same method works for INSERT and UPDATE calls properly so I don't think that's part of the problem.

Advice taken about placeholders. Is the point so that you don't need to prepare every call?

Replies are listed 'Best First'.
Re^2: DBI, rows, and do
by davidrw (Prior) on Jun 05, 2005 at 23:00 UTC
    hmm.. ok, the working for INSERT and UPDATe throws out my previous thoughts..

    how is $rows declared? i see that it is a global.. maybe it's a scope issue? Can you (at least to verify this) have get() do return $rows; and have remove() do my $rows = get("affected"); ?

    As for placeholders, being able to prepare calls for re-use is one advantage.. others include (perhaps best one last):
    • legibility/maintenance of SQL -- not cluttered up with perl variables
    • clarity of variables use -- seeing my @bind = ($x, $y, $z); is much eaiser to see and understand than mentally finding the $'s in the (esp if large) SQL statement.
    • quoting/espacing -- DBI will take care of this for you, and save many headaches of dealing with backslashes/single quotes..
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom