webERP Forum

Full Version: GLPostings causing hard stop when called
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
WebERP crashes when reaching GLPostings.inc (whichever file calls it)  and displays:

Database Error 2006 :
MySQL server has gone away
Database SQL Failure : The SQL that failed was
SELECT counterindex, periodno, account, amount FROM gltrans WHERE posted=0 AND periodno='-8' ORDER BY account

When executing the query directly in phpmyadmin, I do not encounter any problem (I just get an empty result set)

Thank you for your input!

webERP version 4.14.1
It sounds like the mysql server is timing out. You can try increasing the wait_timeout variable in your my.cnf configuration file and see if that changes it.

I have been working on changing the system so that it does away with GLPostings.inc and the chartdetails table altogether. It seems to perform well on a database with more than 2 million GL transactions. If this was something that was of general interest I could write up a specification for it?

Tim
Thanks Tim, I will adjust the setting and see how it goes.
We have a little under 200,000 rows in gltrans.
(12-10-2020, 01:31 AM)falkoner Wrote: [ -> ]I have been working on changing the system so that it does away with GLPostings.inc and the chartdetails table altogether. It seems to perform well on a database with more than 2 million GL transactions. If this was something that was of general interest I could write up a specification for it?

http://www.weberp.org/forum/showthread.php?tid=8424
After investigation and noticing a significant performance drop (log in can take up to 7 seconds), I found out that we actually have 12017 periods defined in our system, going up to year 3019.

Looking at the audit trail, it appears that the damage was caused by one single user within a 5 second timeframe.

What could possibly cause almost 17000 periods being created?
If a user types 04/30/3019 in a bank transaction instead of 2019, I'm assuming it creates all periods between 2019 and 3019, correct?
Yes that is correct

Tim