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

Yes, that is an obvious way, but even then not necessarilly if you retrieve using a HASHREF. 
my $select = qq~SELECT field1 field2 field3 FROM $ref;~;
my $sth = $dbh->prepare( $select );
$sth->execute();
my ($field1, $field2, $field3) = $sth->fetchrow_array;

[download]
Will get things EXACTLY where you want them, so would 
my @inarray = $sth->fetchrow_array();

[download]
Or the alternative of having DBI return and arrayref.

But is the idea fo specifying the specific fields extensible and maintainable? My logic would be that if the table structure changes then wildcard of fields does not need to be changed. If you use the HASHREF methods of collecting the data from DBI then you only need be concerned about the actual fields when you look into the HASH for the values.

Of course I stand to be corrected on this, but I would think that having to change the code as well as the SQL is less maintainable than just having to change the code.

jdtoronto

Just like him: All opinions are purely mine and all code is untested, unless otherwise specified

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

[reply]
[d/l]
      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