in reply to Re: Re: DBI returning mysql columns in strange order.
in thread DBI returning mysql columns in strange order.

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;
}

[download]

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Re: Re: Re: DBI returning mysql columns in strange order.
by mpeppler (Vicar) on Oct 10, 2003 at 17:36 UTC
    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 :-)

[reply]

In Section Seekers of Perl Wisdom