schnarff wrote:
I made my database handle a global variable (or at least I think I did; I'm using strict, and I declared it as "my $dbh = DBI->connect..." outside of any subroutine or block).
This is a common misunderstanding. A global variable is one that is visible throughout all of the program because it sits in a typeglob slot in the symbol table. Package %Foo:: can see globals in package %Bar:: by appending the package name: $Bar::global_baz. If you really need global variables, you want to use the vars pragma. However, since you are using mod_perl, globals are generally not a good thing.
By declaring your variables with my, you are lexically scoping them. With what you have described, if they are declared outside of any subroutine or block, they will be file-scoped -- that is, visible throughout the entire file they are in, from the point they are declared, irrespective of package boundaries.
As for your immediate problem, you asked if the second access to the hashref is empty "because hash references are transient". In order for a hash value to dissapear, one (or more) of a few things need to occur:
As for items one and two, is there any chance that you accidentally made another call to fetchrow_hashref()? You have to have some sort of hash reference in $qref or else Perl is going to complain about using that variable as a hash reference, if you are using strict.
Another thought: are you sure that you are calling check_answer()? and that it's getting called when you expect it to? That's the only other thing that I can think of, as what you have posted looks fine. Perhaps you should post more code?
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
In reply to (Ovid) Re: Second Dereference of Hash Ref from fetchrow_hashref broken
by Ovid
in thread Second Dereference of Hash Ref from fetchrow_hashref broken
by schnarff
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |