www.webdeveloper.com
Results 1 to 2 of 2

Thread: Catchable fatal error: Object of class DB_result could not be converted to string

  1. #1
    Join Date
    Nov 2004
    Location
    Walla Walla, WA
    Posts
    89

    Angry Catchable fatal error: Object of class DB_result could not be converted to string

    I'm at a complete loss, please help me out here. I built a site using PEAR :: DB for database abstraction on my own webhosting server, made sure everything worked, then transferred it to the customer's webhost after having him also install PEAR :: DB. The new site worked up until I tried to ogin the first time. Now every time I try to look at just the home page (or any page), I get:

    Catchable fatal error: Object of class DB_result could not be converted to string in /home/vastdavi/public_html/autumn/check_login.php on line 29


    Now, this check_login.php file is called from db_connect.php (providing all the info to draw data from the database), and db_connect.php is called from the header.php, which is at the start of every page. Login.php calls it too if the login form hasn't been submitted. If it has, only db_connect.php is called so it can access the database to check passwords, and since db_connect.php calls check_login.php, the session_start(); has already been intiated.

    That's how things are arranged. Below is the complete check_login.php script.


    PHP Code:
    <?php 
    // check login script, included in db_connect.php. 

    session_start(); 

     if (!isset(
    $_SESSION['username']) || !isset($_SESSION['password'])) { 
        
    $logged_in 0
        return; 
     } else { 
        
    // remember, $_SESSION['password'] will be encrypted. 

        
    if (!get_magic_quotes_gpc()) { 
        
    $_SESSION['username'] = addslashes($_SESSION['username']); 
        } 
        
    // addslashes to session username before using in a query. 

        
    $password $db_object->query("SELECT `password` FROM `users` WHERE `username` = '".$_SESSION['username']."' LIMIT 1"); 
           if (
    DB::isError($password)) { 
            
    $logged_in 0
            unset(
    $_SESSION['username']); 
            unset(
    $_SESSION['password']); 
            unset(
    $_SESSION['type']); // kill incorrect session variables. 
           

        
    $db_pass $password->fetchRow(); 

        
    // now we have encrypted pass from DB in $db_pass['password'], stripslashes() just incase: 

        
    $db_pass['password'] = stripslashes($db_pass['password']); 
        
    $_SESSION['password'] = stripslashes($_SESSION['password']); 

        
    //compare: 

           
    if ($_SESSION['password'] == $db_pass['password']) { // valid password for username 
            
    $logged_in 1// they have correct info in session variables. 
           
    } else { 
            
    $logged_in 0
            unset(
    $_SESSION['username']); 
            unset(
    $_SESSION['password']); 
            unset(
    $_SESSION['type']); // kill incorrect session variables. 
           
    }//end if passwords match 

     
    }//end if isset SESSION username or password 

    // clean up 

    unset($db_pass['password']); 

    $_SESSION['username'] = stripslashes($_SESSION['username']); 

    ?>
    Now why, using the exact same files on both servers, does my server still work perfectly (I can login, view restricted content, log back out, and see the general public version of the page, etc.), and his server gave me this error AFTER trying to login one, and it won't go away?

    BOTH webhosts are using Apache 2.2.22, PHP 5.2.17, PEAR 1.9.4 (my server was using a slightly older one, I updated, mine still works), and DB 1.7.14 (again, mine was created using the older 1.7.12, but I updated this also to make them match, and my server still functioned flawlessly). The MySQL versions are different, but would that have anything to do with a PHP parsing error??

    What else can I check? Is this a problem with PEAR :: DB somehow (even though all versions are the same on both servers and it works on one), or are sessions not being saved correctly on the new server, or what?
    -Ben Sauve
    www.bensauve.com

  2. #2
    Join Date
    Nov 2004
    Location
    Walla Walla, WA
    Posts
    89
    Here's what I know so far. I changed my login page so tht it shows me what it finds in the database, the matching process, and wht it enters into $_SESSION['password']. It is entering data into that variable, and it can be read before going to the homepage again. As soon as the homepage is loaded, check_login.php uses session_start() at the very beginning of the page, and after that point, it seems that while $_SESSION['password'] is still set (isset($_SESSION['password'])=="1"), it can no longer be read. Every time I try to read it's contents, it says it can't be converted into a string. $_SESSION['username'] can still be read. That carried over fine. So what gives?
    -Ben Sauve
    www.bensauve.com

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles