in reply to Re: DBI don't fetch my data...or at least not all records
in thread DBI don't fetch my data...or at least not all records

Thanks for the help. Of course I should have had some more proper error handling my bad. Anyway I got some more info when enhancing the error handlig, but still it doesn't tell me jack. Here comes the maeesage 
fetch failed  at mungeMarketData.pl line 207, <FILE> line 2494.
 Bad file descriptorERROR: What a pitty: Something went wrong: fetch f
+ailed  at
mungeMarketData.pl line 207, <FILE> line 2494.
 at mungeMarketData.pl line 213
        main::testSql('DBI::db=HASH(0x3f64958)') called at mungeMarket
+Data.pl

[download]

bad FILE descriptor? I don't use a file I try to fetch from a db and that works fine with another table in the same db, same user

Replies are listed 'Best First'.
Re^3: DBI don't fetch my data...or at least not all records (bug?)
by tye (Sage) on Nov 20, 2012 at 18:35 UTC
    bad FILE descriptor? I don't use a file

    It has to connect to the DB somehow. There is almost always a file descriptor under the covers (usually to a socket).

    But it could also be reporting $! even though there wasn't a failure that set $! ("bad file descriptor" is a common error that gets left behind in $! due to common stuff that happens under the covers).

    It looks like a bug to me.

    - tye        

[reply]
      Hi Thanks for answering. Do you mean a bug in DBI or in my program? I would say in DBI ( I might definiteley be wrong) because as I have stated before I do pretty the same select statment for some other columns and the only differece is that in the failing one the column "BBTicker" has the "not null" property set to it, the other "working" "BBTicker" columns in the other tables doesn't.
[reply]

        Most likely a bug in DBD::ODBC, but that is just a guess. It could be a bug in ODBC or in your code or even in DBI, Perl, ODBC, etc.

        Perhaps you should report exactly what data should get returned for the record where this fails, since that seems a likely place for this (possible) bug to have been triggered.

        - tye        

[reply]
Re^3: DBI don't fetch my data...or at least not all records
by kurreburre (Acolyte) on Nov 20, 2012 at 18:34 UTC
    I also made a more "decent" trace and it looks like DBI finds something. The first trace here fails 
          !! info: '' CLEARED by call to prepare method
      -> prepare for DBD::ODBC::db (DBI::db=HASH(0x3fa28a8)~0x3fa2740 
+'select BBTicker, WMRic from FXSpots where id = 218') thr#1639fc8
      <- prepare= ( DBI::st=HASH(0x3fa2d58) ) [1 items] at mungeMarket
+Data.pl line 199
      -> execute for DBD::ODBC::st (DBI::st=HASH(0x3fa2d58)~0x3fa2ad0)
+ thr#1639fc8
      <- execute= ( '0E0' ) [1 items] at mungeMarketData.pl line 200
      -> bind_columns in DBD::_::st for DBD::ODBC::st (DBI::st=HASH(0x
+3fa2d58)~0x3fa2ad0 SCALAR(0x3a15040) SCALAR(0x3a15070)) thr#1639fc8
      <- bind_columns= ( 1 ) [1 items] at mungeMarketData.pl line 201
      -> fetch for DBD::ODBC::st (DBI::st=HASH(0x3fa2d58)~0x3fa2ad0) t
+hr#1639fc8
      <- fetch= ( undef ) [1 items] at mungeMarketData.pl line 202 
    BBticker =  
    WMRic =     
      -> DESTROY for DBD::ODBC::st (DBI::st=HASH(0x3fa2ad0)~INNER) thr
+#1639fc8
      <- DESTROY= ( undef ) [1 items] at perl5db.pl line 3754
      -> DESTROY for DBD::ODBC::db (DBI::db=HASH(0x3fa2740)~INNER) thr
+#1639fc8
      <- DESTROY= ( undef ) [1 items] at mungeMarketData.pl line 63
      -- DBI::END ($@: , $!: )
      !! info: '' CLEARED by call to disconnect_all method
      -> disconnect_all for DBD::ODBC::dr (DBI::dr=HASH(0x3fa20e0)~0x3
+fa2158) thr#1639fc8
    <- disconnect_all= ( '' ) [1 items] at DBI.pm line 741

    [download]
    and this trace succeeded 
       !! info: '' CLEARED by call to prepare method
    -> prepare for DBD::ODBC::db (DBI::db=HASH(0x3ef7a60)~0x3ef78f8 's
+elect BBTicker, CRBTicker from Indices where id = 51') thr#299fc8
    <- prepare= ( DBI::st=HASH(0x3ef7f10) ) [1 items] at mungeMarketDa
+ta.pl line 200
    -> execute for DBD::ODBC::st (DBI::st=HASH(0x3ef7f10)~0x3ef7c88) t
+hr#299fc8
    <- execute= ( -1 ) [1 items] at mungeMarketData.pl line 201
    -> bind_columns in DBD::_::st for DBD::ODBC::st (DBI::st=HASH(0x3e
+f7f10)~0x3ef7c88 SCALAR(0x3965040) SCALAR(0x3965070)) thr#299fc8
    <- bind_columns= ( 1 ) [1 items] at mungeMarketData.pl line 202
    -> fetch for DBD::ODBC::st (DBI::st=HASH(0x3ef7f10)~0x3ef7c88) thr
+#299fc8
    <- fetch= ( [ 'SPGCLV Index' undef ] ) [1 items] row1 at mungeMark
+etData.pl line 203
BBticker = SPGCLV Index
 WMRic =     
    -> DESTROY for DBD::ODBC::st (DBI::st=HASH(0x3ef7c88)~INNER) thr#2
+99fc8
    <- DESTROY= ( undef ) [1 items] at perl5db.pl line 3754
    -> DESTROY for DBD::ODBC::db (DBI::db=HASH(0x3ef78f8)~INNER) thr#2
+99fc8
    <- DESTROY= ( undef ) [1 items] at mungeMarketData.pl line 63
    -- DBI::END ($@: , $!: )
    !! info: '' CLEARED by call to disconnect_all method
    -> disconnect_all for DBD::ODBC::dr (DBI::dr=HASH(0x3ef7298)~0x3ef
+7310) thr#299fc8
    <- disconnect_all= ( '' ) [1 items] at DBI.pm line 741

    [download]
    the only differens I can see is in the fetch method where the failed trace has "undef" whereas the working one has my valid value.
[reply]
[d/l]
[select]
      the only differens I can see is in the fetch method where the failed trace has "undef" whereas the working one has my valid value.
      The difference starts a few lines before: execute returns '0E0' for the first query, but -1 for the second one.
      لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]

In Section Seekers of Perl Wisdom