Re^3: getting the name of a variable to use as string

Replies are listed 'Best First'.
Re^4: getting the name of a variable to use as string by pmneve (Novice) on Sep 20, 2004 at 18:46 UTC
I work in left field ;-). I don't always have access to the data directly from a DBI call. I have to deal with unloads that don't carry column names. Being of the mind that the fewer keystrokes I have to type, the fewer dumb errors I'll have to correct I'm looking for a way to take the results of a split `my ($a, $b, $c, $d) = split(/\\|/,$unloadrow);` [download] and build a hash keyed by the column name (a, b, etc) without having to type each name twice more as in `$hash{'a'} = $a; $hash{'b'} = $b; ...` [download] This may seem lazy but I often have a dozen tables with twenty or more columns to deal with and it would be nice to avoid a lot of error prone and repetitious typing or even cobble up a subroutine to handle building the hash. The goal is to build a hash of those hashes so I can look up individual field values to do analysis of the data. Thanks!	[reply] [d/l] [select]
Re^5: getting the name of a variable to use as string by tachyon (Chancellor) on Sep 21, 2004 at 00:54 UTC
As noted before you almost never want to do it the way you described. Hash slice syntax is what you want. `my %h; my @cols = qw( a b c d ); @h{@cols} = split ' ', 'does this do it?'; use Data::Dumper; print Dumper \%h; __DATA__ $VAR1 = { 'a' => 'does', 'b' => 'this', 'c' => 'do', 'd' => 'it?' };` [download] If you designed this database it is worth noting that each column in a RDBMS should be atomic ie you should not be storing pipe delimited data and then breaking it out as you loose a lot of power. cheers tachyon	[reply] [d/l]
Re^6: getting the name of a variable to use as string by pmneve (Novice) on Sep 21, 2004 at 21:33 UTC
The database itself does not contain pipe delimited data. That's the format of the unloaded flat file I'm forced (in some circumstances) to use. I often must extract data from some 500 individual databases (one per store, obviously) not particularly centralized...), transport it to a central server and process it. Not pretty, but sometimes necessary. I didn't design the database thank goodness. Thanks for your help! That snippet looks like it might help (or show me the error of my ways ;-) ) pat	[reply]