Moodle

Syntax error creating tables on install

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.6, 1.6.1, 1.6.2, 1.6.3, 1.6.4, 1.7, 1.7.1
  • Fix Version/s: 1.7.2, 1.8, 1.9
  • Component/s: Installation, LAMS
  • Labels:
    None
  • Environment:
    Linux
  • Database:
    MySQL
  • Affected Branches:
    MOODLE_16_STABLE, MOODLE_17_STABLE
  • Fixed Branches:
    MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE

Description

I am using a host with a remote database.

PHP version 4.4.2 & 5, MySQL version 5.0.22 & 4.1.2 with Zuse 4.3. using namesco as paid host server.

I have tried both MySQL version and tables halt after creation. Install stops after LAMS table. I bypassed the LAMS table by commenting out nusoap.php in /lib/setup. install moves onto Lesson tables (successful) then stops again. i've managed to get this error message:

(successful creation)

MySQL ERROR:

mysql> explain CREATE TABLE mdl_lams ( id int(10) unsigned NOT NULL auto_increment, course int(10) unsigned NOT NULL default '0', name varchar(255) NOT NULL default '', introduction text NOT NULL default '', learning_session_id bigint(20) default '0', timemodified int(10) unsigned NOT NULL default '0', PRIMARY KEY (id), KEY course (course))COMMENT='LAMS activity';

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CREATE TABLE mdl_lams ( id int(10) unsigned NOT NULL auto_increment, course in' at line 1

I've tried everything i can think of with little progress.

Install halts with no option to continue. I have a working version on another host, the only difference i can see is this one is on a remote database server not @localhost.

I've used both 4.1.2 & 5.0.22 versions of MySQL and PHP 4.4.2 & 5. same happens everytime.

Please help, i've been working on this for over a week.

I can also give login report if its needed??

Thank You

Steve

Activity

Hide
Martin Dougiamas added a comment -

From Eloy Lafuente (stronk7 at moodle.org) Monday, 7 August 2006, 11:00 PM:

Hi Steve,

I really think that 'explain' cannot be used to analyse DDL (create table) statements. It's only for SELECT queries.

I've tried to execute the command against MySQL 5.0.19 and MySQL 4.1.21 and it works without a problem:

create table test (

id int(10) unsigned NOT NULL auto_increment,

course int(10) unsigned NOT NULL default '0',

name varchar(255) NOT NULL default '',

introduction text NOT NULL default '',

learning_session_id bigint(20) default '0',

timemodified int(10) unsigned NOT NULL default '0',

PRIMARY KEY (id),

KEY course (course))

COMMENT='LAMS activity';

The problem with LAMS and NUSOAP was solved a long time ago, if I'm not wrong, by using the lib/soaplib.php that decides about PHP SOAP functions or NUSOAP. And it's not in lib/setup.php at all.

Uhm, strange. Are you sure that you are using the latest 1.6.1+ versión? If so, could be possible that some limit (memory...) was the cause for your installation not ending successfully?

Ciao

From Eloy Lafuente (stronk7 at moodle.org) Friday, 11 August 2006, 08:31 PM:

any news about this....?

From steve Bilton (steveb at sheilds.org) Tuesday, 15 August 2006, 09:59 PM:

I have used the most upto date moodle 1.6.1+ from after your post last post. same happens.

I have checked and it is not a max memory or max time limit problem as they are both set really high. even so i edited php.ini and .htaccess to higher values, still the same happens.

i edited moodle/mod/lams/lib.php. sorry not setup.lib, my mistake. then the install moved on to Lesson from LAMS table after by passing nusoap, and stalled there too.

Ken Wilson has replicated my environment and done a clean install.

I've made many attempts to fix this and have to come the concluion, (with the help of Ken Wilson, an exstremely helpful mooler) the problem lies with a configuration setting on the paid host server. but we cannnot accurately identify what the problem is exactly.

Currently i have asked the host to switch onto a developer server in the hope the configuration settings will be different. If this does not work i will be switching hosts.

Can you recommend a good host service. I may likely be changing to a moodle partner. In the need of 2-5GB storage in the upcomming months.

Or do you have any other suggestions on this problem?

Show
Martin Dougiamas added a comment - From Eloy Lafuente (stronk7 at moodle.org) Monday, 7 August 2006, 11:00 PM: Hi Steve, I really think that 'explain' cannot be used to analyse DDL (create table) statements. It's only for SELECT queries. I've tried to execute the command against MySQL 5.0.19 and MySQL 4.1.21 and it works without a problem: create table test ( id int(10) unsigned NOT NULL auto_increment, course int(10) unsigned NOT NULL default '0', name varchar(255) NOT NULL default '', introduction text NOT NULL default '', learning_session_id bigint(20) default '0', timemodified int(10) unsigned NOT NULL default '0', PRIMARY KEY (id), KEY course (course)) COMMENT='LAMS activity'; The problem with LAMS and NUSOAP was solved a long time ago, if I'm not wrong, by using the lib/soaplib.php that decides about PHP SOAP functions or NUSOAP. And it's not in lib/setup.php at all. Uhm, strange. Are you sure that you are using the latest 1.6.1+ versión? If so, could be possible that some limit (memory...) was the cause for your installation not ending successfully? Ciao From Eloy Lafuente (stronk7 at moodle.org) Friday, 11 August 2006, 08:31 PM: any news about this....? From steve Bilton (steveb at sheilds.org) Tuesday, 15 August 2006, 09:59 PM: I have used the most upto date moodle 1.6.1+ from after your post last post. same happens. I have checked and it is not a max memory or max time limit problem as they are both set really high. even so i edited php.ini and .htaccess to higher values, still the same happens. i edited moodle/mod/lams/lib.php. sorry not setup.lib, my mistake. then the install moved on to Lesson from LAMS table after by passing nusoap, and stalled there too. Ken Wilson has replicated my environment and done a clean install. I've made many attempts to fix this and have to come the concluion, (with the help of Ken Wilson, an exstremely helpful mooler) the problem lies with a configuration setting on the paid host server. but we cannnot accurately identify what the problem is exactly. Currently i have asked the host to switch onto a developer server in the hope the configuration settings will be different. If this does not work i will be switching hosts. Can you recommend a good host service. I may likely be changing to a moodle partner. In the need of 2-5GB storage in the upcomming months. Or do you have any other suggestions on this problem?
Hide
Eloy Lafuente (stronk7) added a comment -

Hi,

I've been performing hundreds (yep, hundreds) of installations in three servers last weeks and I haven't been able to reproduce the problem at all.

So, I'm going to close this as no reproducible, please feel free to reopen if more info is avaliable or the problem persists...

Ciao

Show
Eloy Lafuente (stronk7) added a comment - Hi, I've been performing hundreds (yep, hundreds) of installations in three servers last weeks and I haven't been able to reproduce the problem at all. So, I'm going to close this as no reproducible, please feel free to reopen if more info is avaliable or the problem persists... Ciao
Hide
Eloy Lafuente (stronk7) added a comment -

After a quick look to the LAMS module, it seems that continues using lib/soap/nusoap.php directly and that's a big problem because such library is incompatible with PHP5 boxes having the SOAP extension enabled (but necesary for PHP boxes not having that extension).

That's why lib/soaplib.php was created time ago by Gustav to decide what SOAP implementation to use.

With more and more PHP5 boxes arriving....we should fix this ASAP (1.7 and 1.8 at least).

Ciao

Show
Eloy Lafuente (stronk7) added a comment - After a quick look to the LAMS module, it seems that continues using lib/soap/nusoap.php directly and that's a big problem because such library is incompatible with PHP5 boxes having the SOAP extension enabled (but necesary for PHP boxes not having that extension). That's why lib/soaplib.php was created time ago by Gustav to decide what SOAP implementation to use. With more and more PHP5 boxes arriving....we should fix this ASAP (1.7 and 1.8 at least). Ciao
Hide
Eloy Lafuente (stronk7) added a comment -

Adding some people here....

Show
Eloy Lafuente (stronk7) added a comment - Adding some people here....
Hide
Martin Dougiamas added a comment -

I'm adding Ernie to this bug

Show
Martin Dougiamas added a comment - I'm adding Ernie to this bug
Hide
Martin Dougiamas added a comment -

Anthony from LAMS is working on this. Sourceforge username 'lamsdev'

Show
Martin Dougiamas added a comment - Anthony from LAMS is working on this. Sourceforge username 'lamsdev'
Hide
Martin Dougiamas added a comment -

Any progress on this Anthony? I'm trying to branch 1.8

Show
Martin Dougiamas added a comment - Any progress on this Anthony? I'm trying to branch 1.8
Hide
Anthony Sukkar added a comment -

Switched to using libsoap.php

Show
Anthony Sukkar added a comment - Switched to using libsoap.php
Hide
Eloy Lafuente (stronk7) added a comment -

Hi Anthony,

I've seen your change applied both to MOODLE_17_STABLE and MOODLE_18_STABLE but not to HEAD....

Show
Eloy Lafuente (stronk7) added a comment - Hi Anthony, I've seen your change applied both to MOODLE_17_STABLE and MOODLE_18_STABLE but not to HEAD....

People

Vote (0)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: