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".
  }
}

[download]

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.

In reply to Re: Call stored procedure in perl by ELISHEVA
in thread Call stored procedure in perl by Rocko19

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.