Support Forum

This - as far as I can tell without spending a week testing and analysing! - should do the trick. I am only concerned that it might leave a record behind here and there but nothing, I believe, that would cause any concern. Just perhaps the odd orphaned row.

So this is a series of queries you can run directly:

DELETE FROM wp_sfdigest WHERE topic_id = XXXXX;
DELETE FROM wp_sflinks WHERE topic_id = XXXXX;
DELETE FROM wp_sfpostattachments WHERE topic_id = XXXXX;
DELETE FROM wp_sfposts WHERE topic_id = XXXXX;
DELETE FROM wp_sftagmeta WHERE topic_id = XXXXX;
DELETE FROM wp_sftopics WHERE topic_id = XXXXX;
DELETE FROM wp_sftrack WHERE topic_id = XXXXX;
DELETE FROM wp_sfwaiting WHERE topic_id = XXXXX;
DELETE FROM wp_sfuseractivity WHERE type_id=1 AND item_id = XXXXX;
DELETE FROM wp_sfuseractivity WHERE type_id=6 AND item_id = XXXXX;
DELETE FROM wp_sfuseractivity WHERE type_id=5 AND meta_id = XXXXX;

IF you do NOT use the blog linking plugin then remove the 'sflinks' query.
IF you do NOT use the tags plugin the remove the 'sftagmeta' query.
IF you do NOT use the watch plugin then remove the 'sfuseractivity' query where type_id=1.
IF you do not use the post rating plugin then remove the 'sfuseractivity' query where type_id=5.
IF you do NOT user the subscriptions plugin then remove the 'sfuseractivity' query where type_id=6 AND the 'sfdigest' query.

Replace the table prefix 'wp_' if this is not what you use.

Replace the XXXXX with the topic ID you wish to remove - in each query.

As always we recommend a full database backup be made prior to using these queries. And, I am afraid, as always we offer these queries with no guarantee of success or effect.

Ah I knew there would be something±

In the sfforums table is a column called 'topic_count' and another called 'post_count' which wont get adjusted. In many respects this is, of course, not perfect db management but it actually makes such a huge difference to overall performance that having these value is worthwhile.

We will need another couple of queries to update these values at the end of the deletes,

Go to the forum admin > toolbox > housekeeping and run the 'Rebuild Forum Indexes' against the forum that had the topic(s) manually removed. That should repair the stats count data which should then correct themselves when the stats Cron action is performed.

Yes - I can see even that might take a very long time..
Let's try this instead...

Open the forum in question so you see the list of topics (forum view). Select a topic with a small number of posts and click on the forum tools, Select the 'View Properties' option and then click on the 'verify' button.

Does that work it out?

It made no difference? Even after the stats cron task has run again?