Topic: Newly upgraded 1.1.5 -> 2.0b4 Can't move topics

[Deprecated]

We just discovered that we can't move topics since the upgrade. When you try to you get an error message, "Wrong value type sent to the database. Integer expected." The topic stays where it is.

The error log shows:

Code: [Select]

Wrong value type sent to the database. Integer expected.
Function: moveTopics
Apply Filter: Only show the errors from this file
File: Sources/MoveTopic.php
Line: 493
I checked the code and the file matches the original archive:

Code: [Select]

    // Now that we have all the topics that *should* be marked read, and by which members...
    if (!empty($log_topics))
    {
        // Insert that information into the database!
        $smcFunc['db_insert']('replace',
            '{db_prefix}log_topics',
            array('id_topic' => 'int', 'id_member' => 'int', 'id_msg' => 'int'),
            $log_topics,
            array('id_topic', 'id_member')
        );
    }


Line 493 is the array('id_topic' => 'int', 'id_member' => 'int', 'id_msg' => 'int'). I checked the database and in the smf_log_topics table it has fields for id_topic mediumint( 8) , id_member mediumint( 8) and id_msg int(10). That all looks sensible to me.

I can't figure out what's wrong. I thought since it was logging I would turn off "Moderation, Administration and User Logs" but that didn't help.


BTW we do have "Include database query in error log" set.

[Fustrate]

If you're still having this problem... right before the non-working code, put

Code: [Select]

die(print_r($logs_topics));and see if it's actually putting in three ints. That's how I usually debug weird code.

[Deprecated]

I've been considering adding a print_r statement...

I commented out the failing code and the forum seems to work fine without it. I think the failed access has to do with marking topics and posts read and adjusting the record to reflect that the topic was moved so that read or unread would still be correct.

Since the mod (hack) the urgency of this problem has lessened since we are now able to move topics okay. I've been busy with more urgent problems and will probably return to this topic soon.

[ccbtimewiz]

Is this still a problem and do you still require assistance?

[Deprecated]

Yes, I do, but I think the job is on me first, to put in the print_r and collect the data. I know one way or another I will fix it myself, but I'll appreciate any aid along the way.

This is a very rare error from what I've seen in my following support topics, but it is still non-zero so it's a real problem even if it's a problem for only a very few.

I had intended to work this today but you know how other problems seem to expand and block out the sunlight...

This is very much a live problem, for an unfortunate few. I'm glad you replied to this topic. I've been looking for it off hand for the last day or so. Nice to see it pop up.

[Deprecated]

I finally tracked it down with stuffing MoveTopic.php with print_r statements.

It turned out that I was getting this right before the code for database update for log_topics:

Array (

• => Array (
• => 36967 [1] => 3133 [2] => 4244637086 ) )

36967 = topic number
3133 = member id
4244637086 = way way too high message number (currently maxMsgID ~660,000)

It suddenly dawned me to go look at the member record and it had id_msg_last_visit ~2,xxx,xxx,xxx.

I killed the member and the problem was fixed. Some must die so that others may live.

It was a terminated account used by somebody from SMF who went over to try to fix the forum's original database problem.

Original topic: http://www.simplemachines.org/community/index.php?topic=257895.0

So that's my story and I'm stickin' with it.