We build. You grow.
Get best community software hereStart a social network, a fan-site, an education project with oxwall - free opensource community software
500 error can't solved this | Forum
Syazwan
Jun 19 '14
Hello sorry for problems , recently I had problem with hosting I think and I already bought new hosting and transfered my domain , thought the problem was over but not yet , oxwall can be installed there but it came with 500 internal error , already enable debug mode as in picture below because I've read in other forum first before post this topic , but it show nothing about cause of that error accept just 500 internal error , and before page 500 internal server error appears there's such a long loading , I'll give the picture below .
Modern
Jun 21 '14
I am not a programmer and have very little experience with SQL Databases however from research I have found that this problem is a mysql database problem.
Oxwall have used the INT in the database formation which has a set limitation of 21483647; this means as soon as your database reaches this number the next entry is reset to it time and time again causing the 500 error. See this page Mysql insert query returns ERROR 162 (23000): Duplicate entry 21483647 for key PRIMARY located here: http://stackoverflow.com/...entry-2147483647-for
On my site this happens when my membership reaches just 100 members.
Note:-- Don't do this until you have read the whole of this post.
To solve this problem you will have to go into your data base using PHP and change the INT(11) to BIGINT and change the offest from 0 to 1 and then give BIGINT a ridiculously high number that you should never ever reach e.g. (20) or (25) numbers e.g. BIGINT(20)
However, there is a problem that my limitations in programing came across. I don't know how to do this on an enmass scale e.g changing ALL OF THE INT(11) VALUES TO BIGINT(20) or (25) so for me, it would mean doing it manually starting at the beginning and working through the whole database.
You would then need to go to the PHP file:- /groupware/ow_core/database.php that references all of the old INT values and change them to BIGINT.
You may very well have to access your plugin files to see if they access the your data base and use the INT values. If they do, the INT values in all of those files will have to be changed to BIGINT as well.
Researching this problem I have come to the conclusion that in solving this problem you will probably not be able to do any updates to your Oxwall site or the plugin programs that you have installed. The reason for this is obvious, if all the present documentation is set to BIGINT and a value of say (20) or (25) numbers with an offset of 1 instead of zero in your database. As soon as you install an update your going to get multiple errors as the updates try to reset everything back to INT in your documentation and INT(11) in your database. Also your offsets will be set back to zero instead of the 1 that you changed them to to solve this problem.
Now that Oxwall and the plugin programmers know that this problem exist I would hope that they come up with a permanent solution to the problem. If they don't then from a marketing perspective, the product is effectively rendered useless and a complete waste of everyone's time, money and effort.
From a strategic business perspective which is my area of expertise, this problem should never have been allowed to happen and should have been solved in testing well before the it was made available for distribution to the public.
Oxwall have used the INT in the database formation which has a set limitation of 21483647; this means as soon as your database reaches this number the next entry is reset to it time and time again causing the 500 error. See this page Mysql insert query returns ERROR 162 (23000): Duplicate entry 21483647 for key PRIMARY located here: http://stackoverflow.com/...entry-2147483647-for
On my site this happens when my membership reaches just 100 members.
Note:-- Don't do this until you have read the whole of this post.
To solve this problem you will have to go into your data base using PHP and change the INT(11) to BIGINT and change the offest from 0 to 1 and then give BIGINT a ridiculously high number that you should never ever reach e.g. (20) or (25) numbers e.g. BIGINT(20)
However, there is a problem that my limitations in programing came across. I don't know how to do this on an enmass scale e.g changing ALL OF THE INT(11) VALUES TO BIGINT(20) or (25) so for me, it would mean doing it manually starting at the beginning and working through the whole database.
You would then need to go to the PHP file:- /groupware/ow_core/database.php that references all of the old INT values and change them to BIGINT.
You may very well have to access your plugin files to see if they access the your data base and use the INT values. If they do, the INT values in all of those files will have to be changed to BIGINT as well.
Researching this problem I have come to the conclusion that in solving this problem you will probably not be able to do any updates to your Oxwall site or the plugin programs that you have installed. The reason for this is obvious, if all the present documentation is set to BIGINT and a value of say (20) or (25) numbers with an offset of 1 instead of zero in your database. As soon as you install an update your going to get multiple errors as the updates try to reset everything back to INT in your documentation and INT(11) in your database. Also your offsets will be set back to zero instead of the 1 that you changed them to to solve this problem.
Now that Oxwall and the plugin programmers know that this problem exist I would hope that they come up with a permanent solution to the problem. If they don't then from a marketing perspective, the product is effectively rendered useless and a complete waste of everyone's time, money and effort.
From a strategic business perspective which is my area of expertise, this problem should never have been allowed to happen and should have been solved in testing well before the it was made available for distribution to the public.
The Forum post is edited by Modern Jun 21 '14
Morena Milani
Jun 22 '14
io non sono un programmatore e hanno poca esperienza con database SQL però dalla ricerca ho trovato che questo problema è un problema di database mysql. Oxwall hanno utilizzato il INT nella formazione del database, che presenta una limitazione serie di 21483647; questo significa che, non appena il database raggiunge questo numero la voce successiva viene azzerato ad essa di volta in volta causa l'errore 500. Vedi questa pagina query di inserimento Mysql restituisce ERROR 162 (23000): Duplicate entry 21483647 per PRIMARY chiave si trova qui: il mio sito questo accade quando la mia appartenenza raggiunge a soli 100 membri. Note: -. Non farlo prima di aver letto tutto questo post Per risolvere questo problema dovrete andare nella vostra base di dati utilizzando PHP e modificare l'INT (11) per bigint e modificare il offest 0-1 e poi dare BIGINT un numero ridicolmente alto che non si dovrebbe mai mai raggiungere ad esempio (20) o (25) numeri es BIGINT (20) Tuttavia, vi è un problema che i miei limiti in programmazione imbattuto. Io non so come fare questo su una scala ad esempio enmass cambiare TUTTE LE INT (11) VALORI bigint (20) o (25), quindi per me, vorrebbe dire farlo manualmente a partire dall'inizio e di lavoro attraverso la . intero database Si avrebbe quindi bisogno di andare al file PHP: -. / groupware / ow_core / database.php che fa riferimento a tutti i vecchi valori INT e modificarle per BigInt Si può benissimo avere per accedere ai file dei plugin per vedere se accedono alla vostra base di dati e utilizzare i valori INT. Se lo fanno, i valori INT in tutti quei file dovranno essere modificati per bigint pure. Ricerchiamo di questo problema sono giunto alla conclusione che nella soluzione di questo problema non sarà probabilmente in grado di fare eventuali aggiornamenti al tuo sito Oxwall o i programmi di plugin che avete installato. La ragione di questo è ovvio, se tutta la documentazione è impostato su bigint e un valore di dire (20) o (25) numeri con un offset di 1 invece di zero nel database. Non appena si installa un aggiornamento vostra intenzione di ottenere più errori come gli aggiornamenti cercano di riportare tutto a INT nella documentazione e INT (11) nel database. Anche i vostri offset verranno impostati a zero invece del 1 che li hai cambiato per risolvere questo problema. Ora che Oxwall ed i programmatori plug sanno che questo problema esiste Spero che sono venuti fuori con una soluzione definitiva al problema. Se non quindi da una prospettiva di marketing, il prodotto è effettivamente reso inutile e uno spreco di tempo, denaro di tutti e fatica. Da una prospettiva strategica di business che è la mia area di competenza, questo problema non dovrebbe mai sono stati autorizzati per accadere e dovrebbe essere stato risolto in fase di test ben prima è stato reso disponibile per la distribuzione al pubblico.have this problem I must restore the site as I do? I was caused by loading a plugin I downloaded the error log file
Team
Modern
Jun 23 '14
WARNING - DO A BACK UP OF YOUR DATABASE AND SITE FILES FIRST BEFORE PROCEEDING.
If you go into cpanel then go to the database section and click on PHPMyAdmin then click on your data-base name on the left side.
This will bring up the structure of your data base in a spreadsheet format.
This bit is just for observation purposes.
Look at the first row and traverse your eyes right until you come to the tag named 'STRUCTURE' and click on it. Here you will see several other files. If you look at the 'TYPE' tag you will see the value INT(11), the 11 represents 11 digits input length. The maximum default SQL number value that INT can take 21483647 so when you reach record 21483647 you will not get record 21483648 SQL will try and create another entry for its maximum which is 21483647 which then comes up as your Error 500.
If you traverse your eyes to the right again you will see a tag with a pen and the words 'Change' this is the tag that you would click on to change INT(11) to BIGINT(20) or (25) as described above. However, this will mean you have to go through the whole database and all your Oxwall files that have INT in them and that is going to be a mega pain in the ass. Unless you are a programer that knows how to do it automatically. Obviously having done that, you will run into all of the updating problems as described above.
I am not a programer but knowing this is a repetitive problem that everyone is coming up against time and time again, I would have used a much better method of registering the database tables, perhaps adding a default or attribute of the current time stamp to the BIGINT(20) would overcome the problem.
This is definitely something the Oxwall team needs to look into and resolve with ALL OF THE OTHER DEVELOPERS.
Until they do, the members on my site will never be able to access their profiles and I won't be able to delete any spam accounts. I also suspect that this problem is going to manifest itself in a lot of the other areas of the site as their INT's reach the dreaded 21483647 level.
I also suspect that there is a problem in the AUTOINCRIMENT function or the site is not zeroing out deleted accounts/items and re-using their numbers. This may explain why the 21483647 inputs in the INT's are being used up so quickly.
If you go into cpanel then go to the database section and click on PHPMyAdmin then click on your data-base name on the left side.
This will bring up the structure of your data base in a spreadsheet format.
This bit is just for observation purposes.
Look at the first row and traverse your eyes right until you come to the tag named 'STRUCTURE' and click on it. Here you will see several other files. If you look at the 'TYPE' tag you will see the value INT(11), the 11 represents 11 digits input length. The maximum default SQL number value that INT can take 21483647 so when you reach record 21483647 you will not get record 21483648 SQL will try and create another entry for its maximum which is 21483647 which then comes up as your Error 500.
If you traverse your eyes to the right again you will see a tag with a pen and the words 'Change' this is the tag that you would click on to change INT(11) to BIGINT(20) or (25) as described above. However, this will mean you have to go through the whole database and all your Oxwall files that have INT in them and that is going to be a mega pain in the ass. Unless you are a programer that knows how to do it automatically. Obviously having done that, you will run into all of the updating problems as described above.
I am not a programer but knowing this is a repetitive problem that everyone is coming up against time and time again, I would have used a much better method of registering the database tables, perhaps adding a default or attribute of the current time stamp to the BIGINT(20) would overcome the problem.
This is definitely something the Oxwall team needs to look into and resolve with ALL OF THE OTHER DEVELOPERS.
Until they do, the members on my site will never be able to access their profiles and I won't be able to delete any spam accounts. I also suspect that this problem is going to manifest itself in a lot of the other areas of the site as their INT's reach the dreaded 21483647 level.
I also suspect that there is a problem in the AUTOINCRIMENT function or the site is not zeroing out deleted accounts/items and re-using their numbers. This may explain why the 21483647 inputs in the INT's are being used up so quickly.
The Forum post is edited by Modern Jun 23 '14
bobbi
Jun 23 '14
This sounds like a bad flaw modern are oxwall aware of this and more importantly will it be fixed if true it will bring many sites down and less experienced people will give up and use different software and who can blame them
Team ross
Jun 24 '14
BIGINT is a MySQL data type, which is why even if you change all INT to BIGINT php will try to convert it to INT as it is native php limitations. The only solution in this case is to truncate ow_newsfeed_action_set table.
Also such problem can occur only if you have php of 32 bit
The Forum post is edited by ross Jun 24 '14
Modern
Jun 24 '14
Hmmm, lol the difference in thinking between a provider or programmer and a marketing professional that specialists in customer service.
The fact is, it should not happen period.
Sorry for being abrupt, but I have spent an inordinate amount of hours on this problem and lost numerous members to my site with loads of complaints. Bobbi's statement is so true.
The only solution in this case is to truncate ow_newsfeed_action_set table.
Here, a detailed explanation in plain English as how we would do it would be appreciated by all of the members who are not programmers.
Also, would this statement also suggest that you are saying, if we deleted the ow_newsfeed plugin this problem would go away?
If that is the case, why is it that access to only the members profile produces this error 500 on my site and the news feed works fine?
The fact is, it should not happen period.
Sorry for being abrupt, but I have spent an inordinate amount of hours on this problem and lost numerous members to my site with loads of complaints. Bobbi's statement is so true.
The only solution in this case is to truncate ow_newsfeed_action_set table.
Here, a detailed explanation in plain English as how we would do it would be appreciated by all of the members who are not programmers.
Also, would this statement also suggest that you are saying, if we deleted the ow_newsfeed plugin this problem would go away?
If that is the case, why is it that access to only the members profile produces this error 500 on my site and the news feed works fine?
The Forum post is edited by Modern Jun 24 '14
Team ross
Jun 24 '14
Well, yes, if you disable newsfeed, then you won't need to truncate that table.
There are two kinds of 500 error, .phtml and server misconfiguration. If it is 500.phtml then enable debug mode to see the actuall error, if you always get server misconfiguration error on your profile, then there's something wrong with the server settings, because we checked our routing and everything should work fine.
As to truncating: read this post please: http://www.oxwall.org/forum/topic/11519?page=1#post-58164
