Merged Last post date "42 years ago" - access denied to topic - database errors

kiwi3685 wrote: Not necessarily. There are many more sites where it does NOT happen. Mine for one. So clearly what is required is an understanding about what is common to the sites where it DOES happen.

Agreed! I look after half a dozen websites with Kunena installed but only the one running v2.0.2 is having this problem.

kiwi3685 wrote: I don't use sh404SEF. Could that therefore be the common denominator on sites that do have this problem?

Possibly. It's happening on kunena.org/forum too. Is sh404SEF used here?

Neil.

No, sh404sef isn't used here

ozneilau wrote: Nearly 200,000 instances

I just re-ran the same search and there are nearly 300,000 search results now.

Whatever the problem is it's spreading. Maybe it's a Joomla update or a Kunena update or something else but hopefully worth someone's time to investigate.

Neil.

More info from a hyper aware moderator on our forum, but she's pretty sure her internet connection hiccupped when she went to submit.

However, there's an easy way to prevent this... Before posting to the database, verify that the post has all the key elements. If not, post an error message and ask the user to repost.

@marfisk: what you've written makes perfectly reasonable sense except for one small detail: at the point when the SQL statement is being committed to the database, it is assumed that the necessary information is already packaged and ready for delivery. It is more likely that the database errors that are responsible for the behaviour we're seeing here are caused by the [non-transactional database behaviour of] MySQL server. It's possible that a failure to maintain a reliable Internet connection with the client could be responsible for PHP misbehaviour. Whatever the reason (and our speculation about the cause) it's a fairly straightforward matter to remediate the database damage with a database tool such as phpMyAdmin.

But, I agree, wouldn't it be wonderful to find out why these things happen in the first place ...

If, as I suspect, the cause of the database errors are due to MySQL "going walkabout", then it's nearly impossible for these things to be corrected in Kunena if the database application lacks the means to roll-back from an incomplete package of SQL transactions.

Hmm, so your assumption is that it's filling the topic table as the last step? It would seem more logical for that to be the top of the tree, but only how I envision it.

And yes, that's exactly what I did, not correcting the records which were very broken, but by deleting them. My concern is there is some dependent information beyond that of cleaning up the statistic (which, btw, worked beautifully).

However, if there is no way to fix that assumption that the data is complete, it should be possible to do a quick verification. On the other hand it would be an extra query group so more resource intensive. Maybe the simplest thing would be to make the post deletable.