Re^9: DBI Problem

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.

Comment on Re^9: DBI Problem Download Code

Replies are listed 'Best First'.
Re^10: DBI Problem by huck (Prior) on Sep 30, 2017 at 13:13 UTC
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	[reply]

Replies are listed 'Best First'.

Re^10: DBI Problem
by huck (Prior) on Sep 30, 2017 at 13:13 UTC

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

[reply]