30 August 2011, 8:26

Starting a new thread as this has taken a bit of a turn. Thought I had sorted it but it was not to be... I isolated the problem to this statement: 

 ALTER TABLE notification_internal_activity ADD CONSTRAINT notiinteacti_par_fk FOREIGN KEY (parent) REFERENCES notification_internal_activity (id)

which was failing. Immediately after the failure the innodb status suggested that the constraint already existed, hence the error. Checking the table the *constraint* did exists even though there had been an error.  Putting a 'die' in just before the constraint was created showed it did not exist at that point and running the query by hand worked fine. 

At this point I hacked the upgrade script so that it called the various bits directly and took all the javascript/jason stuff ou of the equation. I put some time stamps on and - very weirdly - these showed getting from start to error in about 30 seconds when the actual elapsed time was over 3 minutes. 

Then - suspecting that something was firing too many SQL commands somewhere I modified lib/dml.php to echo the sql $command every time execute_sql() was called (just after the 'try'). With no other changes the upgrade worked without errors and went through to completion. The time stamps where now sensible and reflected the actual elapsed time. 

How can adding an echo statement into lib/dml.php make such a difference? Even writing this it doesn't sound likely or sensible :)