Split topic error after upgrade from 2.0.3 to 2.0.4

[Argonaut]

Ok. Moved from the update board to the support board. 

Thanks for the update.
But if I want to split older topics in my forum, the following error occurs:

Duplicate entry '0-7' for key 'lastMessage'
File: /home1/freigeis/public_html/forum/Sources/SplitTopics.php
Line: 676

Note: It appears that your database may require an upgrade. Your forum's files are currently at version SMF 2.0.4, while your database is at version 2.0.3. The above error might possibly go away if you execute the latest version of upgrade.php.

In the past 7 years I've updated my forum and the database each time from several versions to the newer ones and a few weeks ago finally from 1.1.17 to 2.0.3. The last update took more than 10 hours because the database size is about 1 GB. So it seems to me that now I must switch the forum into maintenance mode again, the users must wait again and I must pray again that no error occurs while the next 10 or more hours of running the latest "upgrade.php" again.
That really annoys me a lot.

Well, this is not a support question, it's only a statement.

(And maybe you'll find a way to avoid these long and wearying upgrade-sessions.)

this topic is not for support.  Please raise your issues in a topic in the support board.
(I will note, however, that you are doing the upgrade incorrectly - if you are going from 2.0.3 to 2.0.4, there is no need to run upgrade.php. 2.0.3->2.0.4 is a simple patch applied through the package manager. Additionally, the time required for a major version upgrade (1.1.x to 2.0.x) is very different and requires modifications to the database, while a point upgrade like x.x.y to x.x.z usually does not)

Yes, I know that in the patch from 2.0.3 to 2.0.4 are no database modifications, but the error message tells another story.
If there were no error messages during the upgrade process from 1.1.17 to 2.0.3, the upgrade was done correctly. Right? So I obviously haven't done any incorrect operations because no error messages occurred during the whole upgrade process and at the end, the upgrade process was reportet as successfully completed. And there were also no error messages during the update from 2.0.3 to 2.0.4.




Remark:
I've had the same problem with that forum under an older smf version.
www.simplemachines.org/community/index.php?topic=413028.0
The Upgrade from 1.1.17 to 2.0.3 has fixed that problem. Now it seems to be back.

[emanuele]

This is not an issue the upgrade can fix, this comes from some data inconsistency.

Do you have mods installed?
Simply try a "find and repair any error" and "recount statistics".

[Argonaut]

Thank you for your answer.

No, there are no mods installed.

Ok, I will try your suggestions.

[Argonaut]

Now I did the "find an repair" and "recount statistics".
Result is the same as before:



All installed files are up to date:




Well, I can live with this situation but it's annoying. Fortunately it occurs not too often that an older topic must be splitted.
However, the splitting of newer topics works fine.
So if I have a little bit more time, I'll try the small upgrade package and if this is not solving the problem, I'll try the large one.
Or does anyone have other suggestions?

[emanuele]

mmm...
Let's try that one.
Open ManageMaintenance.php (Sources directory), find this piece of code:

Code Select Expand

// Update the latest message of each board.


and just before add:

Code Select Expand


if ($_REQUEST['step'] <= 7)
{
$req = $smcFunc['db_query']('', '
SELECT COUNT(*)
FROM {db_prefix}topics',
array()
);
list($maxTopics) = $smcFunc['db_fetch_row']($req);
$smcFunc['db_free_result']($req);
while ($_REQUEST['start'] < $maxTopics)
{
$request = $smcFunc['db_query']('', '
SELECT /*!40001 SQL_NO_CACHE */ m.id_topic, MAX(m.id_msg) as id_msg
FROM {db_prefix}messages as m
LEFT JOIN {db_prefix}topics as t ON (t.id_topic = m.id_topic)
WHERE m.id_topic > {int:id_msg_min}
AND m.id_topic <= {int:id_msg_max}
GROUP BY m.id_topic',
array(
'id_msg_min' => $_REQUEST['start'],
'id_msg_max' => $_REQUEST['start'] + $increment,
)
);
$topics = array();
while ($row = $smcFunc['db_fetch_assoc']($request))
$topics[$row['id_topic']] = $row['id_msg'];
$smcFunc['db_free_result']($request);

foreach ($topics as $topic_id => $message)
{
$smcFunc['db_query']('', '
UPDATE {db_prefix}topics
SET id_last_msg = {int:id_msg}
WHERE id_topic = {int:id_topic}',
array(
'id_msg' => $message,
'id_topic' => $topic_id,
)
);
}
$_REQUEST['start'] += $increment;

if (array_sum(explode(' ', microtime())) - array_sum(explode(' ', $time_start)) > 3)
{
$context['continue_get_data'] = '?action=admin;area=maintain;sa=routine;activity=recount;step=7;start=' . $_REQUEST['start'] . ';' . $context['session_var'] . '=' . $context['session_id'];
$context['continue_percent'] = round((700 + 100 * $_REQUEST['start'] / $modSettings['maxMsgID']) / $total_steps);

return;
}
}

$_REQUEST['start'] = 0;
}


And run the recount all statistics.
I will take a while, but it should fix all the id_last_msg (hoping the id_first_msg are not broken too).

If you don't feel comfortable doing the changes, try the file attached.