×
Blue Eagle 5 v1.5.3 has been Released (31 Mar 2020)

The Kunena team has announce the arrival of Kunena template Blue Eagle 5 v1.5.3 which is now available for download. This version addresses most of the issues that were discovered in development.

× Topics that are moved into this category are generally considered to be closed. Users may want to add additional information but these topics should not be resurrected in order to discuss new problems or unrelated matters.

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

More
7 years 5 months ago - 7 years 5 months ago #11 by kiwi3685

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.
Last edit: 7 years 5 months ago by kiwi3685.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago - 7 years 5 months ago #12 by ozneilau
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.
Attachments:
Last edit: 7 years 5 months ago by ozneilau.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago #13 by ozneilau

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.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago #14 by xillibit
No, sh404sef isn't used here

I don't provide support by PM, because this can be useful for someone else.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago #15 by ozneilau

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.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago #16 by marfisk
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.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago - 7 years 5 months ago #17 by sozzled
@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.
Last edit: 7 years 5 months ago by sozzled.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago #18 by marfisk
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.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago - 7 years 5 months ago #19 by sozzled

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.
Last edit: 7 years 5 months ago by sozzled.

Please Log in or Create an account to join the conversation.

More
7 years 5 months ago #20 by marfisk
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?

Please Log in or Create an account to join the conversation.

  • Not Allowed: to create new topic.
  • Not Allowed: to reply.
  • Not Allowed: to edit your message.
Time to create page: 0.126 seconds