I think the assembled monks are scratching their heads because there's nothing all that special about an eval{} block. It should be simple enough to test - just compare the results of running your code as is and with the eval { ... }; opening/close lines commented out.

Something else that caught my eye is the way you're calling insert_budget_line_year. The => arrow notation implies you're building a hash from the arguments, but then I'd expect:

@bly_id = insert_budget_line_year (
    bl_id => $bl_id,
    planning_horizon => \@planning_horizon,  # array ref...?
  );
[download]

Perhaps if you showed the pertinent parts of insert_budget_line_year, it might shed more light on what's happening.

Yes I did and it works fine in the eval block but is invisible when passed to the sub

Easy enough to prove it works:

>perl -wMstrict -le
"my $bl_id;
 my @bly_id;
 sub insert_budget_line { return 'foo'; }
 sub insert_budget_line_year { return @_[1,0]; }
 eval {
   $bl_id = insert_budget_line();
   @bly_id = insert_budget_line_year(bl_id => $bl_id);
   };
 print qq{@bly_id};
"
foo bl_id
[download]

How is your  insert_budget_line_year function defined?

Can you post the relevant code of the sub you call?


holli

You can lead your users to water, but alas, you cannot drown them.

Try to recreate the problem with the simplest script possible. Does it still do this if you assign $bl_id a quoted string? What if you replace insert_budget_line_year with lc()?

In the above, $bl_id is visible within the eval block, but it is NOT visible inside of subroutine insert_budget_line_year().

You are retrieving the parameters from @_ inside insert_budget_line_year(), aren't you? Sounds like a stupid question, but then I've seen (and perpetrated) too many *facepalm* bugs.

my $bl_id = "foo";

# code, code, code...

if(1){
    eval{
       my $bl_id = "bar";
       my $res = insert_budget_line_year (
           bl_id => $bl_id,
       );
    }
}

sub insert_budget_line_year {
    print $bl_id,"\n";
}
__END__
foo
[download]