Calendar Restore Error (ntext incompatible with the equal to operator)

Calendar Restore Error (ntext incompatible with the equal to operator)

by Trevor Johnson -
Number of replies: 1

Hi

Have a problem restoring Calendar Events.

We are using Moodle 1.9.4 and MSSQL.

When we restore a course that has calendar events we get the following...

The data types ntext and varchar are incompatible in the equal to operator.
SELECT * FROM mdl_event WHERE courseid=32 AND name='Cert IV Civil Construction Design - Block1' AND description='' AND timestart=1242858600

    • line 686 of lib\dmllib.php: call to debugging()
    • line 481 of lib\dmllib.php: call to get_recordset_sql()
    • line 531 of lib\dmllib.php: call to get_record_sql()
    • line 3671 of backup\restorelib.php: call to get_record_select()
    • line 8008 of backup\restorelib.php: call to restore_create_events()
    • line 51 of backup\restore_execute.html: call to restore_execute()
    • line 175 of backup\restore.php: call to include_once()

The problem is line 3671 of backup\restorelib.php, the call to get_record_select(), the description field is ntext, and MSSQL doesn't like the equal to operator.

If I change that line to use the LIKE operator it works smile ....

"courseid={$eve->courseid} AND name='{$eve->name}' AND description like '{$eve->description}' AND timestart=$eve->timestart");

But I know this is not the correct way to have this fixed...

Has anyone come across this one before, or should I log this on Moodle Tracker?

Average of ratings: -
In reply to Trevor Johnson

Re: Calendar Restore Error (ntext incompatible with the equal to operator)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
This is a fairly common error where developers have written nice standard SQL which does something that MSSQL cannot cope with. For this reason we have a compatibility function that developers have to remember to call, but naturally it is easy to forget since it works without on MySQL and Postgres.

Anyway, if you file a bug in the tracker, it should get fixed.