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

ozneilau wrote: It's also happening to many other websites. Too many to put this down to database corruption...

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.

I don't have enough data to make that judgement, but I do note your comment:

ozneilau wrote: I am using Joomla 2.5.7 and Kunena 2.0.2 and sh404SEF.

I don't use sh404SEF. Could that therefore be the common denominator on sites that do have this problem? There's no doubting that we read of a LOT of issues that plugin seems to cause.

Thanks for your response! I realise this is not easy to fix and Kunena may not be the cause of the problem, but merely where it is showing up.

sozzled wrote: Occasionally we see these issues in a non-transactional database

Nearly 200,000 instances is a bit more than occasionally! (See attached Google Search).

Neil.

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.

marfisk wrote: Maybe the simplest thing would be to make the post deletable.

perhaps but I think that you could only do that if there was some way for the application - the Kunena component - to be able to access the records. If there's a referential integrity issue - as I suspect there is - this is a moot point.

There are, in effect, two questions in this topic.

(1) What is causing the "42 years" / access problem. We know the underlying cause is a database issue. We don't know, yet, the point of origin, what's responsible for causing the database error.

(2) What do you do to fix the problem? We do know the answer here: you need to patch up the database.

I don't understand the answer. Patch up the database how? Do you mean when it occurs go into the database to fix it on a case by case basis? Or am I missing something as far as a real, long term solution?