I think the problem may be the definition of mnet_host2service in install.xml
mnet_host2service hasn't been created. I think the tables before it have and the ones after it have not.

please add following to your config.php and report hte actual problem message here:
@error_reporting(1023);
@ini_set('display_errors', '1');
$CFG->debug = 38911;
$CFG->debugdisplay = true;

I'm having the same problem with Moodle 2.0 (build 20100319). My test box is:

WinXP SP2
MS SQL 2005 (9.00.1399.00)
IIS 5.1
PHP 5.2.9-2 thread-safe
MS FastCGI

After adding the debug code that Petr posted above to config.php I get the following message after the DDL sql execution error:

Debug info: Could not create constraint. See previous errors.<br /><br />CREATE TABLE mdl2_mnet_host2service ( id BIGINT NOT NULL IDENTITY(1,1), hostid BIGINT NOT NULL DEFAULT 0, serviceid BIGINT NOT NULL DEFAULT 0, publish SMALLINT NOT NULL DEFAULT 0, subscribe SMALLINT NOT NULL DEFAULT 0, CONSTRAINT mdl2_mnethost_id_pk PRIMARY KEY (id) )
Stack trace:
line 378 of \lib\dml\moodle_database.php: ddl_change_structure_exception thrown
line 268 of \lib\dml\mssql_native_moodle_database.php: call to moodle_database->query_end()
line 612 of \lib\dml\mssql_native_moodle_database.php: call to mssql_native_moodle_database->query_end()
line 86 of \lib\ddl\database_manager.php: call to mssql_native_moodle_database->change_database_structure()
line 73 of \lib\ddl\database_manager.php: call to database_manager->execute_sql()
line 454 of \lib\ddl\database_manager.php: call to database_manager->execute_sql_arr()
line 406 of \lib\ddl\database_manager.php: call to database_manager->install_from_xmldb_structure()
line 1179 of \lib\upgradelib.php: call to database_manager->install_from_xmldb_file()
line 176 of \admin\index.php: call to install_core()

I've attached some screenshots of my setup and how I reproduce the error.

Not that I'm using MSSQL 2005, not PostgreSQL., so the error isn't specific to PostgreSQL.

Note that I'm using MSSQL 2005, not PostgreSQL., so the error isn't specific to PostgreSQL.

The following MNET tables did get created in the database:

• mdl2_mnet_application
• mdl2_mnet_enrol_assignments
• mdl2_mnet_enrol_course
• mdl2_mnet_host

They are all empty.

And the \lib\db\install.xml file refers to the following Moodle tables which were not created in my database.

mnet_host2service
mnet_log
mnet_rpc
mnet_remote_rpc
mnet_service
mnet_service2rpc
mnet_remote_service2rpc
mnet_session
mnet_sso_access_control

Penny did you use xmldb editor? If yes, I guess the bug is for Eloy

I believe so, and at any rate, I only added two new tables - mnet_remote_rpc and mnet_remote_service2rpc , both of which were much further on in the list.

I get this. I introduced some changes last week trying to fix some constraint names generation... sure I broke this with the new used names caching...

Wow, I'm getting crazy trying to debug-down this. Right now after creating the mnet_host table, our ddl stuff says that mdl_mnethost_id_pk (its PK) exists by using this query:

SELECT name FROM sysobjects WHERE lower(name) ='mdl_mnethost_id_pk'

But two tables below, when asking again by mdl_mnethost_id_pk (when creating the mdl_mnet_host2service table, when executing exactly the same query, our ddl stuff says that the constaint doesn't exist, so no "2..3...4.." suffix is appended to the name, hence the fail.

Sure I'm forgetting something in the trace of the algorithm... grrr, but indeed, the failure is there.

WIP, ciao

Done!

I always forget that the ultimate reason for that cache is to let the generator to know which objects have been already used (because all the statements are created before physically creating the tables).

And after my last changes last week, some cache overlapping was happening. Sadly I installed mysql and ran all the tests and this problem wasn't revealed.

Anyway, it's fixed now. Resolving... and ciao

Just retried this. All tables were created. Closing.

Now Im getting "Setting up of database session failed. Please notify server administrator." Seems like thats a different unrelated problem.

I applied Eloys fix to \lib\ddl\sql_generator.php. Then I created a new blank database and ran the setup. The Moodle 2 (moodle-latest 2.0 100322.zip) installation now finished without this problem recurring.

Hi Andrew,

by default Moodle 2.0 uses DB for session storage. As far as the session-info can be huge it's possible that you need to properly setup the "text size" variable in freetds.conf in order to allow the driver to handle those big pieces of information properly. I'd suggest you to take a look to http://docs.moodle.org/en/Installing_MSSQL_for_PHP (or, if you are using another mssql driver, different from the freetds one... you'll need another configuration settings to allow that).

Ciao

I get this error when I run a backup on a fresh installation of Moodle 2.0 Preview 2:

The environment is Linux:

php.x86_64 5.2.10-1.el5.centos installed
php-bcmath.x86_64 5.2.10-1.el5.centos installed
php-cli.x86_64 5.2.10-1.el5.centos installed
php-common.x86_64 5.2.10-1.el5.centos installed
php-dba.x86_64 5.2.10-1.el5.centos installed
php-devel.x86_64 5.2.10-1.el5.centos installed
php-gd.x86_64 5.2.10-1.el5.centos installed
php-ldap.x86_64 5.2.10-1.el5.centos installed
php-mbstring.x86_64 5.2.10-1.el5.centos installed
php-mcrypt.x86_64 5.2.9-2.el5.centos.3 installed
php-mysql.x86_64 5.2.10-1.el5.centos installed
php-pdo.x86_64 5.2.10-1.el5.centos installed
php-pear.noarch 1:1.8.1-2.el5.centos installed
php-soap.x86_64 5.2.10-1.el5.centos installed
php-xml.x86_64 5.2.10-1.el5.centos installed
php-xmlrpc.x86_64 5.2.10-1.el5.centos installed
php-dbase.x86_64 5.2.9-2.el5.centos.3 c5-testing
php-debuginfo.x86_64 5.2.10-1.el5.centos c5-testing
php-extras-debuginfo.x86_64 5.2.9-2.el5.centos.3 c5-testing
php-imap.x86_64 5.2.10-1.el5.centos c5-testing
php-mhash.x86_64 5.2.9-2.el5.centos.3 c5-testing
php-mssql.x86_64 5.2.9-2.el5.centos.3 c5-testing
php-ncurses.x86_64 5.2.10-1.el5.centos c5-testing
php-odbc.x86_64 5.2.10-1.el5.centos c5-testing
php-pear-Auth-SASL.noarch 1.0.2-4.el5.centos extras
php-pear-DB.noarch 1.7.13-1.el5.centos extras
php-pear-Date.noarch 1.4.7-2.el5.centos extras
php-pear-File.noarch 1.2.2-1.el5.centos extras
php-pear-HTTP-Request.noarch 1.4.2-1.el5.centos extras
php-pear-Log.noarch 1.9.13-1.el5.centos extras
php-pear-MDB2.noarch 2.4.1-2.el5.centos extras
php-pear-MDB2-Driver-mysql.noarch 1.4.1-3.el5.centos extras
php-pear-Mail.noarch 1.1.14-1.el5.centos extras
php-pear-Mail-Mime.noarch 1.4.0-1.el5.centos extras
php-pear-Net-SMTP.noarch 1.2.10-1.el5.centos extras
php-pear-Net-Sieve.noarch 1.1.5-2.el5.centos extras
php-pear-Net-Socket.noarch 1.0.8-1.el5.centos extras
php-pear-Net-URL.noarch 1.0.15-1.el5.centos extras
php-pecl-Fileinfo.x86_64 1.0.4-3.el5.centos extras
php-pecl-memcache.x86_64 2.2.3-1.el5_2 extras
php-pgsql.x86_64 5.2.10-1.el5.centos c5-testing
php-readline.x86_64 5.2.9-2.el5.centos.3 c5-testing
php-snmp.x86_64 5.2.10-1.el5.centos c5-testing
php-suhosin.x86_64 0.9.25-1.el5.centos c5-testing
php-suhosin-debuginfo.x86_64 0.9.25-1.el5.centos c5-testing
php-tidy.x86_64 5.2.9-2.el5.centos.3 c5-testing

Hi Brent,

could you, if possible, report any problem in a new bug? This was already fixed time ago.

Ciao