You need to grab the column names manually:

my $sth = $dbh->prepare($sql);
$sth->execute() || die $sth->errstr;

my $columns = $sth->{NAME};
print IN join( "\t", @{ $columns } ), "\n";

while ( my @row = $sth->fetchrow_array ) {
    print IN join("\t", @row), "\n";
}
[download]

Chris
M-x auto-bs-mode

Chris,

Your solution worked perfectly.

Thanks,
Louis

TMTOWTDI. This strikes me as an OK time to use SELECT *:

# Use LIMIT 1 to keep the database from working 
# too hard 
my $sql = q(SELECT * FROM table LIMIT 1); 
my $sth = $dbh->prepare($sql) or die . . . ;
$sth->execute();

my @col_names = keys %{ $sth->fetchrow_hashref };

$sth->finish();
[download]

There are most certainly better ways, though.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

I strongly disagree - you shouldn't run a select * just to get the column names of another query.

Use the functionality provided by DBI - namely the $sth->{NAME} attribute (or the related NAME_lc and NAME_uc for the lower case and upper case versions) - this will provide column names in the same order as the current query and is completely generic so that it should handle all situations.

Michael

This is not the same thing. Using fetchrow_hashref does not handle double column names in the query.

Please see Re: Re: Field names from DBI? for more details.

The SQL above isn't doing any JOINs, so I don't see how double column names would be a problem. Now, fetchrow_hashref() has other problems, but collisions aren't one of them in this (simple) case.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated