Re: Re: Re: DBI returning mysql columns in strange order.

[dragonchild]

Please stand corrected. *grins*

sub display_table
{
    my ($dbh, $table_name, $columns, $is_ordered) = @_;

    my $sql = 'SELECT ';
    $sql .= join ',', @$columns;
    $sql .= "\n  FROM $table_name";
    $sql .= "\n ORDER BY " . join(',', 1 .. @$columns)
        if $is_ordered;

    print "$sql\n";

    my $sth = $dbh->prepare_cached($sql)
        or die "Cannot prepare '$sql':\n" . $dbh->errstr;

    $sth->execute
        or die "Cannot execute '$sql':n" . $dbh->errstr;

    my $values = $sth->fetchall_arrayref;

    $sth->finish;

    return $values;
}

[mpeppler]

That's certainly a valuable technique.

Unfortunately this breaks down if you have low-level code that executes stored procedures. While the caller will (or should) know what result sets and columns will be coming back, the code that actually executes the proc won't.

For example, I have a system that is table-driven where each database call is described by a small auto-loaded perl subroutine. The higher level code calls this subroutine with appropriate parameters, and then the low-level "execute this request" code runs and fetches all the data. Admittedly the low-level code doesn't have to know about the column names, but it still fetches that information (usually for debugging/trace purposes).

Michael

PS. I'm not disagreeing with you - just pointing out that (as usual) there are exceptions :-)