Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: DBI don't fetch my data...or at least not all records

by kurreburre (Acolyte)
on Nov 20, 2012 at 18:15 UTC ( #1004769=note: print w/ replies, xml ) Need Help??


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

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


Comment on Re^2: DBI don't fetch my data...or at least not all records
Download Code
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
    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
    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 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.
      لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re^3: DBI don't fetch my data...or at least not all records (bug?)
by tye (Cardinal) 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        

      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.

        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        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1004769]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (9)
As of 2014-07-25 23:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (175 votes), past polls