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

Saying it's database corruption doesn't address the root cause. It only addresses the symptom. As far as I can tell with Google, there are more than a few sites with this issue.

Because my site is new and I'm beta-testing, the forum has been emptied numerous times to clear the issue. The issue still occurs about 50% of the time. The key question is what exactly is causing the problem. I gave you guys all the information I could possibly obtain regarding my site configuration in the hopes that maybe you could find a common thread as to why this is happening.

I understand this is free and that the devs are doing this for very little if anything, but it's a problem that extends beyond one site or two. I'm willing and able to provide any additional information you may need. I'm more a systems guy...16 years in IT, but I can get you logs or any other info you may need to troubleshoot the issue.

I had no issues with any other part of the site. You can pin it on MySQL, but there has to be a common factor somewhere. MySQL is used on millions of websites without issue. There has to be a common factor. Either the version of MySQL, version of PHP, conflict with other software, the order software was installed, or some other unknown common factor. It may not be a consistent issue, but it's common enough where I'd consider it a bug.

The real question is what info do you guys need to troubleshoot this issue? Perhaps if everyone that is having the issue posts the results of the Joomla Forum Post Assistant, you might be able to find commonality.

Thanks and I appreciate your efforts.

So it requires MySQL in the technical documents and yet no piece of the software accounts for the fact that MySQL is not a fully transactional database? There are thousands of programs that use MySQL for their database, and yet I've only seen this issue in Kunena. It seems to me that this is a solvable issue, and there are several ways around solving it that I can think of offhand.

The reason I spoke of escalation is the only feedback we're getting here is stating that you're not interested in pursuing this question while the users and administrators that are implementing your software clearly don't think editing the database directly or having corrupt data in the database is an acceptable solution.

Reasonable responses do not include "This is the last I'll say on this matter" but rather "we cannot solve the problem," "it's in the queue for the next patch," or "can you give us more information to troubleshoot it."

Ignoring the problem will not make it go away. You have people interested in a solution here, and willing to dig into their systems and find data for you to get an answer. Take advantage of this resource that's being offered.

I'll give a quick example of a solution I had to add to an application to avoid data corruption:

PHP was not consistently returning a true date value for the date() function, so I had records inserted with the invalid date from 1970. What I did was introduce a loop that checked the date value against the current year before calling the insert. If it had not been correctly set, it tried again until it was. Since like this problem it was a hiccup, not in the DB but in the server, and it was intermittent so hard to track down, 99% of the time, it passed the first validation and continued without interruption, but that 1% of the time that it would have put corrupt data in my database, it had a few milliseconds delay, mostly caused by me making it send me a notification in the hopes of finding a pattern, and neither the users nor the administrators had to care about it.

I have asked the Kunena developers to look at this topic. I cannot give you more information than this.

It would take you less than 2 minutes to fix the problem. Either
(1) Delete the bad record(s) from the database; or
(2) Fix the record(s) by plugging "meaningful" data into the fields that require meaningful data.

It's really as simple as that.

This problem is not isolated to Kunena, as you suggest. You are correct, MySQL is not a fully transactional database (like Oracle or SQL Server) and even on this forum (at www.kunena.org ) we occasionally - once in several thousand messages posted in the forum - see this, too.

I can fix these things in my own server/database. It's not difficult. The issue here is that this happens every now and then but some hosted environments (the cheap, unreliable kinds) have this problem more often. The way to reduce or eliminate the potential for these issues to arise is to start with a reliable hosted platform. I'm sure you would agree with that, wouldn't you?

I have asked the developers to look at this topic and to give it as much attention as they can. However, we also do not want to see development of Kunena halted indefinitely - looking for the proverbial "needle in a haystack" - or slowed down unnecessarily either, wouldn't you also agree? I believe that nothing is impossible but everything has a cost. The question is, how much are we all prepared to pay?

Thank you. That is all that I was asking for. The indication that the developers were aware of the concern and the availability of extra hands, which is how to reduce the research costs.

I'll admit, I've never seen this kind of behavior in other applications, and I work with many, including two other forum softwares (and several installations of same) all running on MySQL. That said, the hosting company I use is a very reliable one, so it may be that the problems were rare enough (and those softwares allowed the user to correct the records) that I didn't notice them.

Because I have a DBA background, my instinct would be to check the values before submitting them, but yes, this would mean a micro slowdown of posting. Personally, I'd say that time loss is crucial for a chat system, but negligible for a forum, but it's not my call to make. Regardless, I'm willing to look into it further on my end should the developers want the assistance.

Thank you for having the devs look into it.

Fixing the individual threads is not a problem, but it's also not practical over the long term. If it happened 1% of the time, that's one thing, but we're averaging 25-50% on new topics (and we only have 4 members...all beta testers).

I'm using a reliable host (the same host I used for a 1500 member Invision PowerBoard site) and I had no issues with the MySQL DB or the site.

I will happily provide any and all assistance they'd need to troubleshoot this further. As the site is still in beta-testing, I can do pretty much anything at this point to help (short of completely killing the rest of the site...too much work into it).

slayer99199 wrote: Fixing the individual threads is not a problem, but it's also not practical over the long term. If it happened 1% of the time, that's one thing, but we're averaging 25-50% on new topics...

slayer99199 wrote: I'm using a reliable host...

slayer99199 wrote: I will happily provide any and all assistance they'd need to troubleshoot this further.

It's a similar story for me. Thanks for getting the developers to look into this and if there's anything else I can do to help (e.g. Forum Post Assistant post etc), please let me know.

Neil.