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

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?

So is the destroy undefined the problem to chase?

No

you havent been paying attention at all have you? Somehow you still think this has to do with ExecuteQuery but it does not.

You want to make sure the session data is flushed before the database(handle) gets closed.

according to http://search.cpan.org/~markstos/CGI-Session-4.48/lib/CGI/Session.pm#A_Warning_about_Auto-flushing the best way is to use $session->flush(); since Explicit flushing after key session updates is recommended.

Another way would be to use my to lexically localize $session only to the blocks it is being actively used rather than having a lexical-global scope. but that relies on autoflushing by the destructor

I am not running anything. My hosting company is running perl.

Lol dude, I think you're getting trolled.

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