in reply to Re^6: DBI Problem
in thread DBI Problem

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

Replies are listed 'Best First'.
Re^8: DBI Problem
by huck (Prior) on Sep 30, 2017 at 03:11 UTC

    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!

[reply]
[d/l]
[select]

      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]

        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]

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

        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]

In Section Seekers of Perl Wisdom