I am sorry. I can't reproduce this here. Looks like for some reason the tables in your database are not created? Can you check?

This happens before the tables are created. When I do the install, I create the database first (since users don't have create database permissions). This error occurs at the step that says "the database exists - do you want to populate it?"

Sorry, I cannot reproduce. Works just fine. I assume something is terribly off with your system considering the other bugs you reported, too. Nobody else reported this issue, either.

So unless you debug yourself or come up with some new info regarding this I will have to close this issue because it is not reproducable for me.

I just did a clean checkout from Git and a clean install, and I get the same error.

The problem may be in Yii.

The error is generated by lines 518-530 of CDbCommand.php:

catch(Exception $e)
{
    if($this->_connection->enableProfiling)
        Yii::endProfile('system.db.CDbCommand.query('.$this->getText().$par.')','system.db.CDbCommand.query');
    $errorInfo = $e instanceof PDOException ? $e->errorInfo : null;
    $message = $e->getMessage();
    Yii::log(Yii::t('yii','CDbCommand::{method}() failed: {error}. The SQL statement executed was: {sql}.',
        array('{method}'=>$method, '{error}'=>$message, '{sql}'=>$this->getText().$par)),CLogger::LEVEL_ERROR,'system.db.CDbCommand');
    if(YII_DEBUG)
        $message .= '. The SQL statement executed was: '.$this->getText().$par;
    throw new CDbException(Yii::t('yii','CDbCommand failed to execute the SQL statement: {error}',
        array('{error}'=>$message)),(int)$e->getCode(),$errorInfo);
}

Which is called by lines 293-301 of InstallerController.php:

// Check if the surveys table exists or not
if ($bDBExists == true) {
    try {
         $this->connection->createCommand()->select()->from('{{surveys}}')->queryAll();
         $bTablesDoNotExist = false;
    } catch(Exception $e) {
         $bTablesDoNotExist = true;
    }
}

So, even though the try/catch clause detects that the tables do not exist, the Yii::log() sub-system writes the log to the screen.

Is that something we can control?

The try/catch should catch it, and it does that here just fine, so I am still wondering why it doesn't do that on your system?

I have

display_errors = On
and
error_reporting = E_ALL

set in php.ini. I still guess it is some configuration issue on your server.

try/catch does catch it; however, CDbCommand's try/catch grabs it first and adds it to the logging system. So, although InstallerController's try/catch works fine, Yii::log() still shows it to the screen, and thus breaks the JSON response used for listing surveys.

I spent a while looking, but couldn't find an easy way to turn off the Yii logging system or get it to write to disk. I'm sure there is a way, but it wasn't obvious.

See http://www.yiiframework.com/doc/guide/1.1/en/topics.logging

Anything?

I spent a little while trying to figure out the logging, but it wasn't very intuitive.

Without logging customizations (e.g. with the default configuration), I still get the same error. This one I can live with, but this is also the root problem for 06162 - I still can't list surveys in 2.0 despite multiple fresh re-installs of LS 2.0

If this starts to affect other people, I'd recommend adding in default logging that fixes this specific problem.

Fix committed to Yii branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=9133

TMSWHite: Please check if it is working now. By default the YII debug mode is now deactivated. You can simply activate it for dev purposes by setting the debug param in config.php after installation or whenever it suits you.

Now I get a new set of errors when I do a fresh install (see attached screen shots). I double checked my php.ini file, and it does not have any debugging turned on.

Fix committed to Yii branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=9146

Try again now, please.

OK, that fixes the config.php errors, but I still get the original error from the database step - see newest screenshot

Can you check (if necessary by inserting the code in the framework) what value the YII_DEBUG constant has when the error is thrown?
if it is false, then it is weird why still an error is thrown, if it is true then the question is where it is set to true.

From what I can see is that an exception is caugth by the framework, which then throws another exception, which then should be caught by the try/catch
in lines 293-301 of InstallerController.php. Only on your system the last step does not happen. Maybe a bug in your PHP version? Which 5.3 version are you using exactly?

Lines 293-301 do catch the error, and the value of YII_DEBUG is false when that error is caught.

The problem stems from lines 350-356 and 518-530 of CDbCommand.php, specifically:

Yii::log(Yii::t('yii','CDbCommand::{method}() failed: {error}. The SQL statement executed was: {sql}.', array('{method}'=>$method, '{error}'=>$message, '{sql}'=>$this->getText().$par)),CLogger::LEVEL_ERROR,'system.db.CDbCommand');

Oddly, however, if I surround the Yii::log() blocks with if (YII_DEBUG) { }, they are never called, yet I still see the log message.

Hmm, actually, is this line (528) in the CDbCommand.php that is the problem:

throw new CDbException(Yii::t('yii','CDbCommand failed to execute the SQL statement: {error}', ('{error}'=>$message)),(int)$e->getCode(),$errorInfo);

Although that exception is caught, somehow it generates a log message anyway.

I am using PHP Version 5.3.5

Perhaps it is a version issue.

I just installed XAMPP 1.8.0, which uses PHP 5.4.4, and everything now works fine.

Wierd. If it is a PHP 5.3 issue (or a 5.3.5 issue), it would be nice to caution users (and/or let them know that an upgrade can fix it). I don't have time to test other PHP 5.3 versions, so perhaps others can report which 5.3 versions are known to work properly with LS 2.0

This one comes close: https://bugs.php.net/bug.php?id=52890

It's not exactly clear in what version this was finally fixed. It might also be a later silent fix-fix.

Anyway, if someone comes around with this kind of bug we know where it comes from so at least something good came out of this.
If you don't mind lets close this issue then.

Fixed by PHP version upgrade