# Fix Fishbowl Error: MySQL Server Has Gone Away > Source: https://netray.co/erp-help/fishbowl-mysql-server-has-gone-away-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer This error means the Fishbowl Server lost its connection to the underlying MySQL database, usually because a session sat idle past MySQL's wait_timeout, MySQL itself restarted, or a large import or report exceeded max_allowed_packet. Raise the relevant MySQL timeout and packet settings, confirm the MySQL service is actually running, and restart both MySQL and the Fishbowl Server service. ## Kind error ## System small-erp ## Erp Fishbowl Inventory / Fishbowl Manufacturing ## Module Fishbowl Server / MySQL Database Connection ## Query Fishbowl error: MySQL server has gone away ## Alternate Queries - Fishbowl database connection lost fix - Fishbowl Server will not connect to MySQL - Fishbowl client unexpectedly disconnected from server - Fishbowl error connecting to database timeout ## Applies To Fishbowl Inventory/Manufacturing 2021 through 2025, on-premise MySQL installs ## Steps ### Resolve a lost MySQL connection in Fishbowl **Items:** - Confirm the MySQL service (MySQL57, MySQL80, or the Fishbowl-bundled MySQL instance) is actually running on the database server. - Check Windows Event Viewer or the MySQL error log for an unexpected MySQL restart around the time the error appeared. - Locate my.ini (Windows) or my.cnf (Linux) for the MySQL instance Fishbowl uses, and open the [mysqld] section. - Increase wait_timeout and interactive_timeout - the MySQL default of 28800 seconds (8 hours) is often too short for a warehouse terminal left open overnight; many Fishbowl installs raise this to a much larger value. - Increase max_allowed_packet, commonly to 64M or higher, if the error appears specifically during large imports, big reports, or attaching large photos or files to records. - Restart the MySQL service so the my.ini/my.cnf changes take effect. - Restart the Fishbowl Server service so client connections re-establish cleanly against the updated MySQL settings. - If the error still recurs only on specific large operations, split the import or report into smaller batches rather than raising timeouts indefinitely. - Rule out a firewall, antivirus, or VPN idle-connection timeout on the network path between the Fishbowl clients/server and MySQL, since those can close the underlying TCP connection independent of MySQL's own settings. ## Sections ### Why MySQL drops the connection **Body:** Fishbowl Server keeps a pool of connections open to MySQL for its clients. MySQL server has gone away fires when one of those connections is no longer valid from MySQL's side by the time a query is sent on it - either MySQL closed it after wait_timeout/interactive_timeout of inactivity, the MySQL service itself restarted or crashed, or the query being sent (an insert with a large attachment, a bulk import) exceeds max_allowed_packet and MySQL terminates the connection rather than accepting it. ### Editing my.ini/my.cnf safely **Body:** Back up the existing my.ini/my.cnf before editing it. Add or update the wait_timeout, interactive_timeout, and max_allowed_packet directives under [mysqld], save, and restart the MySQL service for the change to take effect - MySQL does not pick these up from a config file edit without a restart unless set dynamically via SET GLOBAL. **Code:** - [mysqld] - wait_timeout=604800 - interactive_timeout=604800 - max_allowed_packet=64M ### Network-layer causes (firewalls, VPN idle timeouts) **Body:** If the Fishbowl Server and MySQL run on separate machines, or clients connect over VPN, a firewall or VPN gateway with its own idle-connection timeout can silently close the TCP session before MySQL's own wait_timeout would. This shows the same error even after MySQL's timeouts are raised generously, because the connection never reaches MySQL's timeout at all - the network device drops it first. Check firewall and VPN session timeout settings alongside the MySQL configuration. ### When it points to a bigger database health problem **Body:** If the error correlates with MySQL actually crashing or restarting (visible in the MySQL error log) rather than just an idle timeout, treat it as a database health issue, not a timeout tuning issue - check available disk space, InnoDB log settings, and whether the MySQL data directory is on a drive close to full, since MySQL can terminate unexpectedly under those conditions. ## Pitfalls - Raising max_allowed_packet in my.ini but forgetting the change requires a MySQL service restart to take effect. - Setting wait_timeout extremely high without also addressing a firewall/VPN idle timeout, which still closes the connection underneath MySQL. - Assuming every occurrence is a timeout issue when the MySQL error log actually shows the service crashing or restarting. - Editing my.ini on the wrong MySQL instance when multiple MySQL installs exist on the same server (for example, one bundled with Fishbowl and another used by a separate application). - Not restarting the Fishbowl Server service after fixing MySQL, leaving existing client sessions on stale, already-broken connections. ## Ai Angle Deciding whether MySQL server has gone away is a plain idle-timeout issue, a max_allowed_packet limit hit by one large import, or a genuine MySQL crash usually means cross-referencing the MySQL error log timestamp against when the Fishbowl operation ran. An ERP assistant like Netray's ERPray, grounded in the Fishbowl Server logs and the underlying database's own error log, can correlate the two automatically and state which of the three causes actually applies before anyone starts editing my.ini, instead of a technician guessing which timeout to raise first. ## Faq ### Do I need to restart Fishbowl Server after changing MySQL's my.ini? **Answer:** Yes. Restart the MySQL service first so the new my.ini values take effect, then restart the Fishbowl Server service so existing client connections drop and re-establish against the updated MySQL configuration rather than sitting on stale, already-broken sessions. ### Is max_allowed_packet the same as wait_timeout? **Answer:** No. max_allowed_packet limits the size of a single query or result MySQL will accept, and is usually the cause when the error appears during large imports or attaching big files. wait_timeout/interactive_timeout instead governs how long an idle, unused connection can sit before MySQL closes it, which is the more common cause for terminals left open overnight. ### Could antivirus software cause this error? **Answer:** Yes, some antivirus or endpoint protection tools inspect or throttle local database traffic and can close long-idle connections between the Fishbowl Server and MySQL, producing the same error even with generous MySQL timeouts configured. Excluding the MySQL data directory and connection ports from active scanning is a common fix. ### Where do I find the MySQL error log to check for a crash or restart? **Answer:** Its location is set by the log-error directive in my.ini/my.cnf, and defaults to a .err file inside the MySQL data directory on most installs. Check its timestamps against when the Fishbowl error occurred to see whether MySQL actually restarted rather than simply timing out an idle connection. ## Search terms fishbowl mysql server has gone away, fishbowl database connection lost, fishbowl server wont connect to mysql, fishbowl mysql wait_timeout, fishbowl max_allowed_packet error, fishbowl mysql my.ini settings, fishbowl client disconnected error, fishbowl database timeout fix, fishbowl mysql crash restart --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json