in reply to how to avoid a reference?

That's not really a reference, that's a symbolic reference which is something a bit different. I hope you mean that you want to avoid symbolic references (which is entirely sensible) not that you want to avoid real references (which would be a bit silly).

The best way around your program would be to use a multi-level hash (called something like %people whic contains all of your data. It would look something like this:

my %people; foreach my $person (@people) foreach my $value (@dbmlist) { my %VAL; dbmopen(%VAL, $value); $people{$value}{$person} = $VAL{$person}; dbmclose(%VAL); } }

A couple of other points that might make your life easier:

  1. The "dbmopen" and "dbmclose" functions have been deprecated for some time. Try looking at "tie" instead.
  2. If you're storing all of the data in a sinlge hash called %people, why not store it all in a single DBM file using MLDBM.
--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Replies are listed 'Best First'.
Re^2: how to avoid a reference?
by Aristotle (Chancellor) on Aug 07, 2004 at 16:27 UTC

    why not store it all in a single DBM file using MLDBM.

    Or DBM::Deep.

    Makeshifts last the longest.

Re^2: how to avoid a reference?
by ysth (Canon) on Aug 08, 2004 at 05:30 UTC
    dbmopen and dbmclose are not AFAIK deprecated. There is a note in perlfunc that they are "largely superseded by" tie and untie, but it takes several lines to get tie to do what dbmopen does for you.
      Several lines? Let me compare:
      # Using dbmopen dbmopen(my %foo, 'data.db', 0666); # time passes... dbmclose(%foo); # Using tie use DB_File; tie(my %foo, 'DB_File', 'data.db'); # time passes... untie(%foo);
      Doesn't seem like that much extra to me.

      Furthermore dbmopen and dbmclose may not be officially deprecated, but I'd suggest that people not use them.

      Of course if you don't mind the possibility that installing a new module will cause working scripts to break and you to be left not knowing how to get at your data, then by all means ignore my advice. The extra information that you have to supply for tie removes a potentially painful ambiguity.

      (The fault actually lies with AnyDBM_File.)