Posted by espirates on December 23, 2009 at 12:16pm
8 followers
| Project: | Webform |
| Version: | 6.x-2.9 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference.
Please continue to the error page
An error occurred. /update.php?id=113&op=do <br /> <b>Fatal error</b>: Call to undefined function _system_update_utf8() in <b>/sites/all/modules/webform/webform.install</b> on line <b>384</b><br />
user warning: Unknown column 'ws.name' in 'field list' query: SELECT ws.nid, ws.sid, wc.cid, ws.name, ws.data FROM webform_submitted_data ws, webform_component wc WHERE ws.nid = wc.nid AND ws.name = wc.name in /sites/all/modules/webform/webform.install on line 332.
user warning: Table 'webform_submissions' already exists query: CREATE TABLE webform_submissions ( nid int(10) unsigned NOT NULL default '0', sid int(10) unsigned NOT NULL default '0', submitted int(11) NOT NULL default '0', PRIMARY KEY (nid, sid) ) in /sites/all/modules/webform/webform.install on line 354.
The update process was aborted prematurely while running update #3 in webform.module. All errors have been logged. You may need to check the watchdog database table manually.
Comments
#1
The question is *why* are you running update_3? That update was added some time in the Drupal 4.7 version, so unless you're upgrading from Drupal 4.7 to Drupal 6, you shouldn't be running that update anyway. This error was likely caused by the administrator running update.php, then manually selecting an update number (which you should NEVER do, it's purely for development purposes and has been removed entirely from Drupal 7). If you've re-run all the Webform updates, you've likely permanently damaged your Webform installation and will need to restore a database backup or completely uninstall and re-install webform.
#2
uh ? I never used 4.7, I've been using Drupal 6 for a long time now and been keeping up to date as well. I recently upgraded to Drupal 6.15. How could this have happen ?
#3
The only way it could happen would be if an administrator went to update.php, expanded the "Available updates" fieldset, then manually changed the update number from the automatically assigned one to an earlier number.
#4
oh I see, maybe I did it by accident, using Opera browser, sometimes you click and it does something you didn't expect, thanks.
#5
FWIW, I had the same thing happen to me when I was careless and tried to "upgrade" from 6.x-3.x-dev to 6.x-2.9 If you try to do that, update 1 is automatically selected, which, of course, is completely wrong.
#6
I got almost the same thing, except it was running the information below:
* user warning: Unknown column 'ws.name' in 'field list' query: SELECT ws.nid, ws.sid, wc.cid, ws.name, ws.data FROM webform_submitted_data ws, webform_component wc WHERE ws.nid = wc.nid AND ws.name = wc.name in /sites/all/modules/webform/webform.install on line 332.
* user warning: Table 'webform_submissions' already exists query: CREATE TABLE webform_submissions ( nid int(10) unsigned NOT NULL default '0', sid int(10) unsigned NOT NULL default '0', submitted int(11) NOT NULL default '0', PRIMARY KEY (nid, sid) ) in /sites/all/modules/webform/webform.install on line 354.
The following queries were executed
webform module
Update #1
* CREATE TABLE {webform_tmp} ( nid int(10) unsigned NOT NULL default '0', sid int(10) unsigned NOT NULL default '0', cid int(10) unsigned NOT NULL default '0', no int(10) unsigned NOT NULL default '0', data longtext, PRIMARY KEY (nid, sid, cid, no) )
* DROP TABLE {webform_submitted_data}
* ALTER TABLE {webform_tmp} RENAME TO {webform_submitted_data}
* Failed: CREATE TABLE {webform_submissions} ( nid int(10) unsigned NOT NULL default '0', sid int(10) unsigned NOT NULL default '0', submitted int(11) NOT NULL default '0', PRIMARY KEY (nid, sid) )
Update #2
* ALTER TABLE {webform} ADD redirect_post int(1) UNSIGNED NOT NULL DEFAULT '0' AFTER confirmation
--------------
Then it stops. How do you fix this? I didn't manually choose any version to update.
Thanks!
#7
Hello,
I have the same problem.
I never user 4.7; but from last update i see that I can't go to /node/add/webform because system don't known webform as content type (but I have some forms working).
And if I try to upload again all files and run update.php I have error page that show:
Fatal error: Call to undefined function _system_update_utf8() in /sites/all/modules/webform/webform.install
on line 384
... also that I try to update from older version. Is possible that files to download from file server (http://ftp.drupal.org/files/projects/webform-6.x-2.9.tar.gz) of webform are out of date?
Thanks for all!
#8
Same issue here, just downloaded and upgraded to webform-6.x-3,0-beta5.tar.gz. Webform is totally crashed now.
An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference.
Please continue to the error page
An error occurred. http://www.mydomain.com/update.php?id=10&op=do
Fatal error: Call to undefined function webform_component_include() in /home/name/domains/mydomain.com/public_html/sites/all/modules/webform/webform.install on line 1090
#9
OK, mine may have something to do with Webform Conditional... I turned off and deleted both Webform and Webform Conditional, uploaded again and updated.... still got some errors but when I turned them on, everything is back up and working.
#10
Setting to active again..having the same and did not ever changed something manually...
greetings, Martijn
#11
This patch should prevent the problem in 3.x when users are attempting to upgrade Webform while the module is disabled.
@nasinandes: Note that if you're getting the problem because of _system_update_utf8() missing, it's because you're running updates (likely by manually selecting them) that are no longer meant to be run. Webform should auto-select the updates that need to be run. If you've manually overridden them you've likely damaged your database.
#12
Automatically closed -- issue fixed for 2 weeks with no activity.