# QAD Says "Unable to Connect to the Application Server": How to Fix It > Source: https://netray.co/erp-help/qad-unable-to-connect-to-appserver-error-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer 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. ## Kind error ## System small-erp ## Erp QAD Enterprise Applications (QAD Adaptive ERP) ## Module System Administration - Progress AppServer Connectivity ## Query QAD unable to connect to the application server ## Alternate Queries - QAD .NET UI cannot connect to appserver - QAD Enterprise Applications connection to server failed - QAD Progress AppServer broker will not start - QAD login fails cannot reach server ## Applies To QAD Enterprise Applications (MFG/PRO) 2015 EE through QAD Adaptive ERP, using the QAD .NET UI, QAD Desktop client, or QAD Web UI connecting to a Progress OpenEdge AppServer. ## Steps ### Diagnose and fix the AppServer connection **Items:** On the application server, open OpenEdge Explorer or Progress Explorer and confirm the QAD AppServer broker (for example, qadapp or the broker name configured for your instance) shows a status of Running. If the broker is stopped, start it from OpenEdge Explorer rather than restarting the whole server, and watch for errors in the broker startup log. Open the broker's .log file (under the working directory set on the broker's Properties tab) and look for lines showing agent startup failures, database connect failures, or propath errors. From the client machine, confirm you can reach the broker's host and port with a simple network test (telnet or Test-NetConnection on Windows); a blocked port after a firewall change is one of the most common causes. If you use a Progress NameServer (nsman) for name-based connections, confirm the NameServer process is running and that the broker registered with it - a broker running but not registered will still fail client lookups. Check the number of active AppServer agents against the broker's configured Maximum Clients Per Agent and Maximum Agents; if every agent is busy or the licensed user count is exceeded, new connections are refused. If the broker log shows an agent crashing immediately on startup, especially right after a patch or code push, recompile the QAD .r code for that AppServer's PROPATH and restart the broker. Verify the connection string in the QAD .NET UI client profile or web.config points to the correct host, port, and service name, not a decommissioned or renamed server. After making a change, restart the broker cleanly (stop, confirm the port is released, then start) rather than layering a second broker instance on the same port. ## Sections ### Why the error points at the broker, not the database **Body:** QAD's .NET UI and Web UI do not talk to the Progress database directly. They call a Progress OpenEdge AppServer broker, which hands the request to an agent process that runs the compiled QAD business logic (.r code) and then queries the database on the agent's behalf. When a user sees "unable to connect to the application server," the failure happened before the database was ever reached - at the broker or the network path to it. This is why restarting the database server rarely fixes this specific error. The database can be perfectly healthy while the broker service is stopped, out of agents, or unreachable because of a firewall rule, a changed IP address after a server move, or a certificate issue on an encrypted connection. ### Reading the broker log **Body:** The broker's log file, set under the broker's working directory in OpenEdge Explorer, is the fastest way to tell what actually failed. A line referencing the database connection parameters usually means the broker itself cannot reach the QAD database (wrong -db, -H, or -S startup parameters). A line referencing an agent failing to initialize, especially citing a specific .r file or PROPATH entry, points to a code or compile problem rather than networking. Agent crash-on-startup after a patch is a recurring pattern: a partial code push leaves stale or missing .r files, the agent fails its first request, and the broker marks it unusable, which quickly drains the pool and produces connection failures for every new user. **Code:** - OpenEdge Explorer > AppServer > > Log tab - OpenEdge Explorer > AppServer > > Properties > Startup Parameters ### Licensing and agent pool exhaustion **Body:** QAD and Progress OpenEdge licensing caps the number of concurrent connections. If the broker's Maximum Agents and Maximum Clients Per Agent settings are undersized for your active user count, or if a batch job or integration left sessions open without releasing them, legitimate users get refused with the same generic connection error a hard outage would produce. Check active agent and client counts in OpenEdge Explorer against the licensed count before assuming the broker configuration is wrong; sometimes the fix is simply killing orphaned sessions rather than changing settings. ### Network path and firewall changes **Body:** Because the AppServer listens on a specific TCP port (and, if you use a NameServer, a second port for name lookups), any firewall rule change, VPN reconfiguration, or move to a new subnet can silently break client connectivity while leaving the broker itself perfectly healthy. This is common after a server migration or a security team tightening outbound rules. Test connectivity from the actual client machine, not just from the server, since server-to-server access can work while client-to-server access is blocked. ## Pitfalls - Restarting the whole application server instead of just the affected broker, which causes unnecessary downtime for unrelated services. - Assuming the database is down because the error message is generic, and skipping the broker log entirely. - Increasing Maximum Agents without checking the actual licensed user count, which just moves the failure to a licensing violation later. - Not recompiling .r code after a patch, so the broker keeps spawning agents that immediately crash on the same missing module. - Forgetting the NameServer when troubleshooting name-based connections, and only checking the broker. - Changing the client connection string on one machine to confirm a fix, then not rolling the change out to the rest of the user base. ## Ai Angle When an AppServer connection issue like this comes in as a support ticket, ERPray can be grounded on the broker logs, prior incident notes, and the QAD environment documentation so it can point a support engineer straight at the specific broker, the relevant log lines, and the last configuration change that lines up with the outage, instead of the team re-walking the broker versus database versus network checklist from scratch each time. ## Faq ### Does this error always mean the AppServer broker is down? **Answer:** No. The broker can be running but still refuse connections if it is out of licensed agent slots, if the NameServer it registers with is down, or if a firewall change blocked the client's path to the broker's port. Check the broker log first to narrow it down. ### Why did this start happening right after a QAD patch? **Answer:** Patches that update .r code without a full recompile and clean broker restart can leave agents crashing on startup. Recompile the affected code for the broker's PROPATH and restart the broker rather than just the client. ### Can too many idle user sessions cause this error? **Answer:** Yes. Sessions left open by an integration, a crashed client, or a batch job still count against the broker's agent and license limits. Review active sessions in OpenEdge Explorer and clear orphaned ones before increasing capacity. ### Is the fix different for QAD Web UI versus the .NET UI? **Answer:** The underlying broker troubleshooting is the same either way, since both go through the same AppServer layer. The difference is where the connection string lives - a client profile for the .NET UI versus a web.config or environment setting for the Web UI. ## Search terms QAD unable to connect to appserver, QAD AppServer broker not starting, QAD .NET UI connection error, QAD Enterprise Applications login failure, Progress OpenEdge AppServer troubleshooting, QAD Adaptive ERP connection failed, QAD broker log errors, QAD NameServer not registering, fix QAD server connection issue --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json