Re^8: DBI Problem

Replies are listed 'Best First'.
Re^9: DBI Problem by tultalk (Monk) on Sep 30, 2017 at 12:11 UTC
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.	[reply] [d/l]
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]
Re^9: DBI Problem by tultalk (Monk) on Sep 30, 2017 at 13:09 UTC
"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.	[reply]
Re^10: DBI Problem by huck (Prior) on Sep 30, 2017 at 13:39 UTC
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	[reply] [d/l]
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]
Re^12: DBI Problem by huck (Prior) on Sep 30, 2017 at 16:13 UTC
Re^13: DBI Problem by tultalk (Monk) on Oct 01, 2017 at 00:47 UTC
Some notes below your chosen depth have not been shown here
Re^13: DBI Problem by Anonymous Monk on Sep 30, 2017 at 16:41 UTC
Re^12: DBI Problem by poj (Abbot) on Oct 01, 2017 at 16:17 UTC


laziness, impatience, and hubris
	PerlMonks