Problem during D5->D6 upgrade

I stand corrected, the version with which this problem occurs is 6.x-1.4.

Perhaps the reason why the function was undefined is because the module was disabled when update.php was run? If having the module in enabled state is required for the upgrade, then there should be an appropriate message displayed about it like in Views and CCK modules.

Indeed enabling the module before re-running update.php eliminates the undefined function error. Now I "only" get these two errors:

    * user warning: 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 ')' at line 3 query: UPDATE forum_access SET grant_view = 0, grant_update = 0, grant_delete = 0 WHERE rid IN () in .../sites/all/modules/forum_access/forum_access.install on line 224.
    * user warning: 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 ')' at line 3 query: DELETE FROM node_access WHERE realm = 'forum_access' AND gid IN () in .../sites/all/modules/forum_access/forum_access.install on line 229.

Thanks for the additional information.

To clarify, I was following the upgrade guide which says to disable all optional core and contributed modules at the beginning of the migration process, then run update.php. It doesn't urge you to enable the modules before running update.php, and in fact updating most of the disabled modules works just fine. It makes sense that a module should stay disabled before its database schema is brought up to date (to prevent errors or worse data corruption). The few modules that *do* in fact require being enabled warn you about it when you try running update.php on them. I suggest for usability reasons that you also implement this same warning in your module.

update.php doesn't care whether a module is enabled or disabled - it offers all modules for upgrade, so I'm not doing anything especially weird there. However, what I did was select the 6000 (or equivalent first 6xxx) update for each module myself and then run update.php for just this single module. The reason for this cumbersome step-by-step procedure was the experience gathered from my first upgrade attempt. When I went the supposedly "smooth and easy" path of running update.php over everything offered at once (42 modules), I ended up with tons of error messages that were difficult to associate with each module. I got significantly fewer errors during my second try - I suppose it worked better because update.php doesn't properly respect module dependencies and I was able to upgrade in a more intelligent order.

Finally, the reason why I used 6.x-1.4 as target (rather than 6.x-1.5) is that the whole process began some two months ago and at that time 6.x-1.4 was the most recent version. Also, I don't use dev versions as a matter of policy (it's easier to track changes against officially numbered versions, if changes are needed).

Thanks for pointing this out. I concur that UPGRADE.txt is a good place to look for specification of the official behavior. Yet I still consider a check in update script a best practice from the usability and perhaps even safety viewpoint. Firstly, the user might simply forget to re-enable the module, in which case it's nicer to tell her about it rather than throw strange errors at her. Secondly, I can imagine cases where enabling too many modules prematurely might have bad side effects. Are all modules coded so that they can operate in a safe degraded state before their schema updates have been run? And what if your module's update script depends on another module, which has not been updated yet, but which is already enabled? Given that your update might be chosen by update.php to run first, you might end up using a half-baked helper module that either generates errors or (worse) does something silly which corrupts data.

That's what I meant with update.php not respecting dependencies - it's clear that it cannot be entirely solved through dependency checking while enabling out-of-date modules. Granted, this broader issue and worst-case-scenarios do not really have much to do with this particular bug report. The sum of the story is, I was unaware and mistaken trying to update disabled modules, yet it would have been nice if forum_access could have protected me against that mistake. I also suspect that what I did might not be truly "unsupported" after all, otherwise update.php should have categorically guard against it (also: other modules' authors such as CCK/Views would be rallyng for core to implement this protection in update.php instead of doing the work themselves). FYI, I also submitted a similar request with a patch to forum.module at http://drupal.org/node/569872, but haven't got a response from the maintainer yet.

"Never play with version combos" is good advice in normal circumstances and will certainly save the novice user from messing up their db, but it is sometimes not possible to follow in practice:

• some update scripts are buggy, so sometimes you actually do have to re-run an update after having seen, understood and corrected an underlying cause for an error; unfortunately, the error handling is poor, so an update scripts may not abort when an error is encountered, especially true for SQL errors;
• displaying errors is poorly implemented (and possibly difficult to implement better), so it is hard to associate errors with modules and individual update functions when you run a bunch of updates all at once, which is especially true during major version migration.

I hope that while removing the combos in D7 the devs thought about these issues!