http://www.perlmonks.org?node_id=794086

Rocko19 has asked for the wisdom of the Perl Monks concerning the following question:


Hi,
I want to call a stored procedure and pass certain values to it but I am getting error
$sql .= $sth->bind_param(":IN_App_Name", $app_name); Can't call method "bind_param" without a package or object reference a +t db1.pl line 118.
I guess there is some syntax error in inovking the procedure or bind param is not used properly. Please help!!
Rocko

Replies are listed 'Best First'.
Re: Call stored procedure in perl
by ELISHEVA (Prior) on Sep 08, 2009 at 09:41 UTC

    That message usually means that the thing to the left of -> is undefined. In this case, that would be $sth.

    Without seeing how you go from putdata() to line 118, it is hard to tell why $sth is undefined. Normally croak would cause your program to die, but in this case you've surrounded croak with an eval so all that is happening is that you are reaching the line ##>>>>> Check for errs... with $sth undefined. From there, one of two things may be happening:

    First, you may have reached the code where you roll back, but the code above line 118 doesn't check for a 0 return value from putdata. Even if you reach the rollback code you may not be seeing the error message if you are running in an environment that redirects STDOUT. Your error message is being sent to STDOUT, rather than STDERR. Generally it is better to print error messages to STDERR so they don't get mixed up with whatever output your program needs to send to STDOUT when your query is successful. It also makes it less likely that you will miss error messages when you have a legitimate reason to send STDOUT to file. Finally, it gives you the option to redirect error messages to a log file without losing your normal output. To print error messages to STDERR, use print STDERR "print this".

    The second possibility is that you are dying BUT, for whatever reason, $@ is set to a false value. This can happen sometimes if dying triggers error handling code that clears $@ before you exit the eval. For this reason, it is usually best to write your error handling code like this:

    eval { # your code here } or do { if ($@) { #respond to error $@ } else { print STDERR "Something bad happened at " . __FILE__ . ", line " . __LINE__ . " but I don't know what!\n". } }

    When eval dies it always returns false, so the eval {...} or do {...} sequence insures that you will always end up in your error handling block, no matter what $@ is set to.

    You may also find it helpful to take a look at Devel::EvalError which has a nice example showing why you can't rely on $@ to detect errors and a discussion about some alternatives that let you reliably detect when your code has died.

    Best, beth

    Update: added link to Devel::EvalError.

Re: Call stored procedure in perl
by almut (Canon) on Sep 08, 2009 at 09:25 UTC
    $sql .= $sth->bind_param(":IN_App_Name", $app_name);

    It seems your $sth does not hold a DBI statement handle (where are you setting it?) — that's what the error message indicates.

    Also, I wouldn't know what $sth->bind_param(...); would return that you could usefully concat with your $sql ...   Update: maybe you meant to concatenate code snippets to be eval'ed later:

    $sql .= '$sth->bind_param(":IN_App_Name", $app_name)';

    (note the single quotes) — though then, the "BEGIN CONSOLE(..." wouldn't be valid Perl code...