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

Indeed. select * from ... is really bad form (although expedient when you are in a hurry, I'll admit).

That said the fundamental problem of the OP's code, as has been noted in one of the previous responses, is the reliance on the order of hash keys - I'd like to stress that one should retrieve column names via $sth->{NAME} (or the NAME_lc/NAME_uc variations) as that will correctly list all the column names in the proper order.

Michael

Replies are listed 'Best First'.
Re: Re: Re: DBI returning mysql columns in strange order.
by neilwatson (Priest) on Oct 09, 2003 at 23:34 UTC
    There is a method to my madness. I choose select * from ... because the code is meant to work on a collection of tables whose columns are all different.

    My application involved having a group of small tables. Then I would have this code query and display any table that was selected. I'm trying to be lazyTM

    Neil Watson
    watson-wilson.ca

[reply]
[d/l]
      Well - as long as you are aware of the pitfalls of that technique...

      Michael

[reply]

      With respect, this is not a good enough reason to use SELECT * - I'll try to explain why.

      The main danger is that at some future time, someone (perhaps not you) will add a BLOB column to one of your tables. If this happens, your code as is could blithely start dragging this data across a network. I don't know MySQL so well, but in SQL Server this could be anything up to about 2GB, perhaps more. Plenty enough to provoke the wrath of most Network Administrators.

      You might be lucky - your code could fail due to some exceeded limit, or you might be unlucky - your code could work, and quietly start a mammoth data transfer.

      If you really have your heart set on your current approach, you might want to consider thinking about a maximum limit to the amount of data returned in a column, and then explicitly set this limit with code similar to this:

          $dbh->{LongReadLen}=1024*200;  # Max size of column data
    $dbh->{LongTruncOk}=0;         # Not OK to truncate data

      [download]
[reply]
[d/l]
        Which is why DBI drivers should default the LongReadLen value to some reasonable amount (DBD::Sybase defaults it to 32K as that is the normal default for Sybase connections), and I see that the DBI manual actually states that the default should be 0, meaning "do not fetch BLOB columns" (and made me realize that DBD::Sybase does not behave correctly when LongReadLen is set to 0...)

        Michael

[reply]

In Section Seekers of Perl Wisdom