in reply to Re^9: DBI Problem
in thread DBI Problem

If you pay more attention you will find that it is the first call to executequery that is now failing.

You are running 5.8.8, i think its 5.26.something that is now the bleeding edge, that is a long time for you to not have updated perl and its modules.

it is not a problem with DBI.pm, notice how the error message referrers to CGI::Session::Driver::DBI.pm. And as the warning in the CGI::Session documentation points out it is not as much a bug as it is YOUR fault for letting the database be closed before the flush can be run by the desctuctor.

the destructor for the session variable runs when it goes out of scope and is released. when does that happen? (hint it has nothing to do with execute query, in fact your focus on this being a problem with execute query is misguided.) executequery has nothing to do with $session and $session->flush() should not be in it at all

Replies are listed 'Best First'.
Re^11: DBI Problem
by tultalk (Monk) on Sep 30, 2017 at 14:58 UTC

    You are running 5.8.8, i think its 5.26.something that is now the bleeding edge, that is a long time for you to not have updated perl and its modules.

    I am not running anything. My hosting company is running perl. But, that version is not the problem, correct?

    So I am looking in all the wrong places for all the wrong answers.

    Where specifically would you suggest I look?

    The first query returns the desired result. So the session goes out of scope after that first query is run. Why? And how to work around that?

    All the other calls to executequery are not followed by a second call. This one is unique.

[reply]

      Where specifically would you suggest I look?

      The first query returns the desired result. So the session goes out of scope after that first query is run. Why? And how to work around that? Please show us why you feel $session has a valid value when the first call to executequery gets executed. Please explain why you feel $session goes out of scope after the first query is run. Please explain why you feel a need to flush the session buffers in executequery at all. Please explain what $session has to do with executequery at all.

      I am not running anything. My hosting company is running perl. I f you are not running anything how does your website even function. You are running 5.8.8 released 2006-02-02 yet you say that is quite a while for it to go unfixed. Even though the author points out it is not a bug in his code but a fault in YOUR CODE in that you are letting the database get closed before flushing the session data, you complain that it should have been fixed by now even though your perl has not even been updated since before then.

      All the other calls to executequery are not followed by a second call. This one is unique. This has nothing to do with executequery except that you wrongly try to flush the session data there. It might help if you hand inspect your code paying attention to when $session gets assigned a valid value, when it is getting used and when it goes out of scope

[reply]

        Tried $dbh->trace(2);

        Sat Sep 30 18:42:26 2017 manage_users.cgi: call after 2nd execute: 'DBI::db=HASH(0x21ec980)' dsn: 'dbi:mysql:database=jalamior_assoc_mgr;host=localhost' at /home/jalamior/www/httpsdocs/cgi-bin/lib/perl/manageusers.pm line 684.

        -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x1f09930)~INNER)

        <- DESTROY= undef at manage_users.cgi line 245

        -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x21ecca0)~INNER)

        --> dbd_st_finish

        >- dbd_st_free_result_sets

        <- dbd_st_free_result_sets RC -1

        <- dbd_st_free_result_sets

        <-- dbd_st_finish

        <- DESTROY= undef at manage_users.cgi line 245

        ! -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x1f09520)~INNER)

        Freeing 1 parameters, bind 0 fbind 0

        ! <- DESTROY= undef during global destruction

        >> DESTROY DBI::db=HASH(0x21ec870) clearing 1 CachedKids

        ! -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x21ec870)~INNER)

        imp_dbh->pmysql: 227bfe0

        ! <- DESTROY= undef during global destruction

        Sat Sep 30 18:42:26 2017 manage_users.cgi: (in cleanup) Can't connect to data source '' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at /usr/local/lib/perl5/site_perl/5.8.8/CGI/Session/Driver/DBI.pm line 26

        DESTROY= undef at manage_users.cgi line 245 

        manageusers::OpenConnection(); #This is called for update member info
Line 245---> if (!UpdateUserData($sid,$password,$email,$secret)) {
##                   manageusers::CloseConnection();
                   CreateUserFeedbackForm("Update of Member informatio
+n failed. Please contact the office.");
                     return;
                        }
                else {
#                   manageusers::CloseConnection();
                   CreateUserFeedbackForm("Update of Member informatio
+n succeeded.");
                   #Need to email back to office.
                   return; 
                   }
           return;

        [download]

        So is the destroy undefined the problem to chase?

[reply]
[d/l]
        I am not running anything. My hosting company is running perl.
        Lol dude, I think you're getting trolled.
[reply]
      Where specifically would you suggest I look?

      Answering that question would be made easier if you posted the complete manage_users.cgi script (suitably redacted of sensitive information) here.

      poj
[reply]
[d/l]

In Section Seekers of Perl Wisdom