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.

Why is it that the globally scoped session would not be visible in the executequery?
Being visible and containing a valid value are two different things entirely

by setting the scope of $session via my when it is assigned you insure it is only visible when it contains a valid value. If you had so limited the scope of session in the beginning then when the desctructor for session tried to run the flush the database would not have been already closed either.

i did not suggest anything with tsid or sid, the logical scoping operator "my" has nothing to do with either of them

"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.

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

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.