Re^9: DBI Problem

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

Comment on Re^9: DBI Problem

Replies are listed 'Best First'.
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
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	[reply]
Re^13: DBI Problem by tultalk (Monk) on Oct 01, 2017 at 00:47 UTC
Re^14: DBI Problem by huck (Prior) on Oct 01, 2017 at 01:39 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
Where specifically would you suggest I look? Answering that question would be made easier if you posted the complete `manage_users.cgi` script (suitably redacted of sensitive information) here. poj	[reply] [d/l]