No tsk tsk

package manageusers;

use strict;
use diagnostics -verbose;
use warnings;
use CGI;
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
use CGI qw(:standard escapeHTML);
use CGI qw/:standard/;
use Data::Dumper;

use Digest::MD5 qw(md5_hex);
use CGI::Session;
use CGI::Cookie;
use Mail::Sendmail;
use Time::HiRes qw(usleep);
use Time::Local;
[download]

session is given a value when a user logs on. The user can do different things including changing password in the user table which is what this block of code is supposed to do..

Session is given a value here $session = OpenSession($dbh,$tsid);

Your use of globally scoped lexical variables has gotten you in trouble before too, when you dont know what you are doing it is a bad practice.

i suspect the flush belongs in OpenSession

Again i ask where in ExecuteQuery is session given a value?, Pay attention now, HOW DO YOU INSURE SESSION HAS A VALUE WHEN ExecuteQuery IS CALLED so you can use it to call the flush method?

It should be  my $session = OpenSession($dbh,$tsid); and my $session  = new CGI::Session("driver:MySQL", $sid, {Handle=>$dbh, LockHandle=>$dbh}); to insure session has a value when you use it rather than being possibly unitialized like it is at times now!

You say: Your use of globally scoped lexical variables has gotten you in trouble before too, when you dont know what you are doing it is a bad practice.

Quite true.

Why is it that the globally scoped session would not be visible in the executequery?

What do you mean this "and" this? my $session and my $session???

my $session = OpenSession($dbh,$tsid); and my $session  = new CGI::Ses
+sion("driver:MySQL", $sid, {Handle=>$dbh, LockHandle=>$dbh})
[download]

What are you suggesting with $tsid since that is only locally scoped in many code blocks. If you mean $sid that is not visible in executequery.

"insure session has a value when you use it rather than being possibly unitialized like it is at times now!"

This poses an intersting question

The sub which is the original subject of this thread call executequery twice. The first time executes properly and returns the requested result set. the second call to executequery fails due to $session being out of scope while it was in scope for the first call.

The article links you sent this same scoping subject imply that this is due to a bug in the DBI.pm code. This was reported in 2007 and the later article in 2013. If this is indeed a bug, that is quite a while for it to go unfixed.

The article from 2007 says manual flushing would avoid this issue of going out of scope. I don't understand this problem as I put code in the executequery to check the DBI handle before and after the actual execute and the DBI handle is valid both on the first pass and the second pass when it fails.

Obviously I am no expert in these things and need help understanding what is happening.