in reply to Re^2: uninitialized value in Tk::DBI::Table
in thread uninitialized value in Tk::DBI::Table

Well I can barely feel my way around DBI stuff myself, and I've never used Tk::DBI::Table, so I really can't say what the glitch is. Maybe someone else knows. All I can tell you to do is this: try to get the simplest example possible which works the way you want. Then start adding the extras into it, until it fails, then try to sort out the reason. So maybe try a very simple $sql_query statement, and see if you can get it to work, like "select * from statusmessages" or whatever is the simplest. You probably have some syntax error in the $sql_query.

Like for starters...you have

when statusType = '1' then 'Debug'
maybe that should be == (or eq) not = ; which is sort of hinted at in the error message 4 times....

Use of uninitialized value in string eq

= is for assignment

== or eq is for testing equality

You may need 'eq' if you quote your numbers.


I'm not really a human, but I play one on earth. flash japh

Replies are listed 'Best First'.
Re^4: uninitialized value in Tk::DBI::Table
by runrig (Abbot) on Feb 16, 2005 at 22:25 UTC
    The '=' you are referring to is from a sql statement, not a perl statement, so it is for equality, not assignment.
      Yes, but he did have his numbers quoted, like '1' , '2'; and he did get 4 errors, one for each line with a style like
      = '1' = '2' = '3' = '4'
      saying "unitililized eq in statement...". So why is the error saying 'eq' if it's supposed to be = ?

      Is it the quoted numbers, or should it be 'eq'; or if he unquotes his numbers, == ?


      I'm not really a human, but I play one on earth. flash japh

        The '=' is from a sql statement, it is not executed as perl code. Numbers or not, the equality comparison operator for sql is '='. It should have nothing to do with what happens when the column heading is selected to sort. It's likely that the numbers are quoted because it is a character field in a table that happens to have numbers in it, but that shouldn't matter either.

        My guess at the source of the problem is that he is using Tk::DBI::Table 0.01 (0.01 line 294 looks more likely than 0.02 line 294), one (or more) of the date/time columns is null, and he is getting uninitialized warnings during the sort of that 'uninitialized' column. Seeing a small sample of the data selected that still displays this problem could confirm this.