in reply to DBI::Sybase sometimes returns nothing, but does not generate an error -> how can I catch this?

Perhaps you need to set $dbh->{FetchHashKeyName} = 'NAME_lc'; (You should be able to tell by printing @{$sth->{NAME}} after the execute) (update: then again, you say it works most of the time, so I'm not sure this is the problem).

Other comments: you set RaiseError on the connect (good for you), but check for errors on the next line. If there is an error on connect, the program will not reach the next line (for DBI 0.91 and later). The handle_db_error() function will never be called either (RaiseError causes the program to die with an error message). If you want special processing of errors, either use HandleError, or wrap all your DBI code in an eval block and check $@ afterward.

  • Comment on Re: DBI::Sybase sometimes returns nothing, but does not generate an error -> how can I catch this?
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: DBI::Sybase sometimes returns nothing, but does not generate an error -> how can I catch this?
by svenXY (Deacon) on Jan 12, 2005 at 07:46 UTC
    Hi and thanks for the quick reply!

    Actually, I had not set RaiseError before to be able to handle errors myself via the handle_db_error() function (as I use log4perl).

    I was hoping setting RaiseError would eventually solve my problem, but it doesn't look like it does. Just dieing is not what I'm looking for ;-)

    I have the strange feeling that this driver sometimes doesn't completely work.
    I connect to a MSSQL database in the States and I'm in Germany. I have seen these errors where no error is reported a couple of times now.
    Actually, the starnghe thing is that the resultset is empty although it shouldn't be, but no error is generated.

    What I want to achieve at least is to find out if the resultset is empty before calling fetchall_hashref and assignning it to a variable.
    Will try with eval, but have so far no idea how to prevent this error from showing up on stdout/stderr.

    Cheers, Sven