Jump to:

4945 Posts in 17751 Topics by 1494 members

Installing SilverStripe

SilverStripe Forums » Installing SilverStripe » Trouble with DataObjects after pear upgrade?

Getting SilverStripe up and running on your computer and on your web server.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Page: 1
Go to End
Author Topic: 1719 Views
  • sychan
    Community Member
    5 Posts

    Trouble with DataObjects after pear upgrade? Link to this post

    I'm getting up to speed on the latest release of SilverStripe and came across a problem after going through a couple of tutorials and then using pear to install PHPUnit. I'm running Silverstripe 2.3.5 with MAMP 1.8.4
    I had been trying to run the /dev/tests/all stuff to see what the output was like, but it would not run, complaining that PHPUnit was not installed. After tracking down where MAMP puts pear, and upgrading pear and installing PHPUnit, I am unable to get silverstripe to run at all - all that happens once I enter the silverstripe directory is a "Website Error"

    It looks like there is some issue with the DataObject connecting to the mysql backend, but it isn't clear what the problem is. Here's the text of the error message:

    [02-Feb-2010 03:45:02] Error at sapphire/core/model/DataObject.php line 2520: DataObjects have been requested before the database is ready. Please ensure your database connection details are correct, your database has been built, and that you are not trying to query the database in _config.php. (http://localhost:8888/silverstripe-v2.3.5/dev/build?flush=1)

    Here's the contents of _config.php:


    global $project;
    $project = 'mysite';

    global $databaseConfig;
    $databaseConfig = array(
    "type" => "MySQLDatabase",
    "server" => "localhost",
    "username" => "root",
    "password" => "root",
    "database" => "SS_mysite",

    // Sites running on the following servers will be
    // run in development mode. See
    // http://doc.silverstripe.com/doku.php?id=devmode
    // for a description of what dev mode does.

    // This line set's the current theme. More themes can be
    // downloaded from http://www.silverstripe.com/themes/



    When I look at the phpMyAdmin processes tab, I can see that there is a connection to the mysql listener, bound to the SS_mysite database. I can also use Sequel Pro to connect to localhost port 8889 as root/root and I go right into the database with no issues. Neither the apache nor the mysql logs give any errors.

    Looking at the contructor for MySQLDatabase, I would have expected a "Couldn't connect to MySQL Database" for a basic connection error. After looking at the source code, its especially weird because the phpMyAdmin says that there's a db connection and it has selected SS_mysite, but then DB::globalconn->active should be true since it is set when the mysql_select_db selects SS_mysite.

    Does anyone have an idea what might be the cause? Did the pear upgrade break something?


    I started putting some debug statements into the code, and it looks like databaseConfig['database'] is set to "tmpdb4075729" which _doesn't_ exist. Though I see that there is a tmpdb6855694 laying around with 99 tables in it.

  • Hamish
    Community Member
    712 Posts

    Re: Trouble with DataObjects after pear upgrade? Link to this post

    that error is usually caused by trying to view the site before building your database - although i'm not sure how that impacts on test runners.

    try building anyway by running /dev/build?flush=1

    note that silverstripe creates temporary models (databases) to run tests on, so it is expected that the database doesn't exist.

    Also, for easier debugging, turn on dev mode (see the wiki)

  • sychan
    Community Member
    5 Posts

    Re: Trouble with DataObjects after pear upgrade? Link to this post

    Thanks for the reply - turning on dev mode was very useful. I still was not able to run anything like a /dev/build?flush though.
    But after putting in some debug calls and being able to see all the debug into, I was able to figure out that the $_SESSION variable contained an alternativeDatabaseName field that was overriding the settings in _config.php. Reading through the Session comments, it looks like this may have been set when I tried to run the unit tests. Restarting the browser cleared the session data and things are working again.

    Thanks for the tip!

Page: 1
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.