Fix Fishbowl Error: MySQL Server Has Gone Away
Fishbowl error: MySQL server has gone away
Also searched as
- Fishbowl database connection lost fix
- Fishbowl Server will not connect to MySQL
- Fishbowl client unexpectedly disconnected from server
- Fishbowl error connecting to database timeout
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.
Applies to: Fishbowl Inventory/Manufacturing 2021 through 2025, on-premise MySQL installs
Resolve a lost MySQL connection in Fishbowl
- 1Confirm the MySQL service (MySQL57, MySQL80, or the Fishbowl-bundled MySQL instance) is actually running on the database server.
- 2Check Windows Event Viewer or the MySQL error log for an unexpected MySQL restart around the time the error appeared.
- 3Locate my.ini (Windows) or my.cnf (Linux) for the MySQL instance Fishbowl uses, and open the [mysqld] section.
- 4Increase 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.
- 5Increase 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.
- 6Restart the MySQL service so the my.ini/my.cnf changes take effect.
- 7Restart the Fishbowl Server service so client connections re-establish cleanly against the updated MySQL settings.
- 8If the error still recurs only on specific large operations, split the import or report into smaller batches rather than raising timeouts indefinitely.
- 9Rule 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.
Why MySQL drops the connection
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
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.
[mysqld]
wait_timeout=604800
interactive_timeout=604800
max_allowed_packet=64M
Network-layer causes (firewalls, VPN idle timeouts)
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
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Do I need to restart Fishbowl Server after changing MySQL's my.ini?
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?
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?
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?
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.
Related
How to Create a Generic Inquiry in Acumatica
Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.
Error fixFix Odoo AccessError: You Are Not Allowed to Access Records
Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.
How-toHow to Void a Check in Sage 100
Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.
How-toHow to Run Requirements Planning (MRP) in SYSPRO
SYSPRO's MRP engine lives under Planning and Scheduling > Requirements Planning. Set planning parameters per warehouse, run the Requirements Calculation to net demand against supply, then review and release the resulting suggestions as purchase requisitions or work orders. A full regenerative run typically runs on a schedule, with net change runs in between to pick up new activity.
Error fixQAD Says "Unable to Connect to the Application Server": How to Fix It
This error almost always means the Progress OpenEdge AppServer broker behind QAD is stopped, unreachable over the network, or out of licensed connections, not a database problem. Confirm the broker process is running and healthy in OpenEdge Explorer, check the port and firewall path from the client, then restart the broker with clean agent settings.
How-toHow to Close a Job in JobBOSS2
A job in JobBOSS2 will not close cleanly until every routing operation is marked complete, all material has been issued or returned, and all labor and cost transactions are posted. Review the job's Work In Process detail first, clear any open items, then change the job status to Complete and run final job costing before it is locked.
AI for ERPAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
AI for ERPA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
Stuck on Fishbowl Inventory / Fishbowl Manufacturing?
Talk to engineers who work inside Fishbowl Inventory / Fishbowl Manufacturing every week, and who build private AI that answers these questions from your own ERP data.