The Ignition Gateway initiates the database request. The path runs from the Gateway process through a matching JDBC driver, the host network stack, every intervening network hop, and the SQL server listener. A missing driver stops the path inside the Gateway before any database packet leaves the machine. Follow the packet and prove each layer in order.
Where does the Ignition database request stop?
Classify the failure before changing the installation. Ignition 8.0 beta may not include the driver required by the installed SQL database because licensing and distribution restrictions prevent bundling many database drivers. On a clean installation, plan to obtain and install the required JDBC driver. On an upgrade, the existing driver should normally remain in place; its absence indicates an upgrade or migration problem rather than a normal clean-install condition.
| Installation case | Expected driver state | First decision |
|---|---|---|
| Clean Ignition 8.0 beta installation | The required database driver may be absent | Obtain the driver that matches the existing database |
| Upgrade of an existing Gateway | The previously installed driver should already be present | Investigate whether the driver was omitted, removed, or failed to migrate |
| Local test Gateway beside another Gateway | Each Gateway must have access to its own required driver configuration | Decide whether to keep the test installation separate or manage distinct Gateway ports |
A driver-loading error, missing driver entry, or inability to create the database connection object points to the Gateway or JDBC layer. A socket refusal, timeout, or authentication response means processing advanced farther down the path. Record the exact status and error text from the Gateway before proceeding.
Check: Confirm whether the installation is clean or upgraded, then verify whether the required JDBC driver is present in that Gateway.
Can the Gateway reach the SQL server at layer one?
Layer one first. Installing a driver cannot repair a disconnected interface, invalid route, blocked path, or inactive SQL listener. Identify the machine running the Gateway and trace the physical and logical route to the database host. For a local database, the path remains within the host network stack; for a remote database, it includes the Gateway interface, switches or wireless infrastructure, routers, security controls, and the database interface.
| Path item | Value to obtain | Verification |
|---|---|---|
| Gateway address | Read from the Gateway host network configuration | Confirm the expected interface is active |
| Database address | Read from the database host or approved connection configuration | Resolve the configured name to the intended host |
| SQL listener port | Read from the SQL server listener configuration | Test that exact address-and-port pair from the Gateway host |
| Connection timing | Read elapsed time and timeout behavior from Gateway diagnostics | Separate immediate refusal from delayed timeout |
An immediate refusal usually means the target host answered but nothing accepted the connection on the selected port, or a security device actively rejected it. A delayed timeout points toward packet loss, filtering, routing, or a nonresponsive destination. Name resolution failure occurs before either result and must be corrected at the host-name or DNS layer.
Do not copy an address or listener port from an unrelated walkthrough. Read both from the actual database installation. Testing only host reachability is insufficient because a host can answer network probes while its SQL listener remains unavailable.
Check: From the Gateway machine, prove that the configured database address resolves correctly and that the configured SQL listener port accepts a connection attempt.
Which JDBC driver must be installed?
The driver must match the database product and the runtime requirements of the Gateway. Obtain it from the database manufacturer or another approved distribution channel. Do not substitute a similarly named driver merely because it appears in an older walkthrough; the Gateway needs a driver capable of translating JDBC calls into that database’s wire protocol.
| Driver setting | Where to obtain it | Failure if wrong |
|---|---|---|
| Database family | Existing SQL server installation | The driver cannot speak the server protocol |
| Driver package | Approved database-driver distribution | The Gateway cannot load the required implementation |
| Driver class or type | Driver documentation and Gateway driver configuration | The package may exist but cannot be instantiated |
| Connection URL format | Driver documentation | The driver loads but cannot interpret the destination |
Driver availability in the Ignition 8.0 beta line was changing: some drivers were expected to return, while others required separate installation through a guided process. Treat the active Gateway configuration as authoritative. A driver listed in one installation does not prove that a clean beta installation bundles the same package.
- Identify the database product behind the existing SQL server.
- Inspect the Gateway’s installed database-driver list.
- If the correct entry is absent on a clean installation, download the matching JDBC driver through an approved channel.
- Add it through the Gateway’s supported driver-installation process, supplying the driver metadata requested by that process.
- Confirm that the Gateway accepts and loads the driver without a driver-class or package error.
Check: The Gateway must display the required driver as installed and loadable before a database connection is configured.
How should the database connection be configured?
Once the driver loads, configure the connection to the address and listener port already proven from the Gateway host. The connection also needs the correct database target and credentials. Keep transport failures separate from authentication and authorization failures: a login rejection proves that the network and driver carried the request far enough for the SQL server to evaluate credentials.
- Select the installed driver that matches the SQL database.
- Enter the database host name or address verified during the network check.
- Enter the listener port read from the SQL server configuration.
- Enter the required database name or target using the driver’s documented connection format.
- Supply an account authorized for the intended Ignition database operations.
- Save the connection and inspect its status plus the exact diagnostic text.
| Observed result | Stopping point | Next action |
|---|---|---|
| Driver cannot load | Gateway driver layer | Correct the driver package or its configured metadata |
| Name cannot resolve | Host-name resolution | Correct the name or resolver configuration |
| Connection refused | SQL listener or active filtering | Verify the configured listener and exact port |
| Connection times out | Network path or passive filtering | Trace routing and security controls |
| Login rejected | SQL authentication | Correct credentials or database permissions |
Check: The connection status must advance beyond driver and transport errors; if it fails, the returned diagnostic must identify the next layer to correct.
How should a second Ignition Gateway be commissioned?
A separate machine keeps the test Gateway’s services, ports, drivers, and maintenance boundary isolated from the active Gateway. Installing another Gateway on the existing server can also work when each service uses distinct, nonconflicting ports. The tradeoff is operational: every maintainer must know which Gateway uses each port, and host-level resource or service changes can affect both installations.
| Deployment | Advantage | Recurring pitfall |
|---|---|---|
| Separate machine | Clear service and failure boundary | The new clean installation still needs its own JDBC driver |
| Same server, different Gateway ports | No additional host required | Port conflicts or connecting to the wrong Gateway interface |
If both Gateways run on one server, inventory their configured service ports before starting the second installation. Do not confuse Gateway service ports with the SQL listener port: changing a Gateway’s web or service port does not change the database destination. Install and verify the JDBC driver in the Gateway that will own the database connection.
Check: Open the intended Gateway using its assigned service port, confirm its identity, and verify that no port conflict appears before configuring its database connection.
How is the connection verified end to end?
Verification must prove more than a green connection indicator. It must show that the intended Gateway loads the selected JDBC driver, reaches the intended SQL listener, authenticates to the intended database, and completes a database operation.
- Restart or reload only as required by the supported driver-installation workflow.
- Confirm the driver loads without package or class errors.
- Open the database connection status on the intended Gateway.
- Confirm that the configured host, listener port, database target, and account belong to the intended SQL installation.
- Execute the Gateway’s supported connection validation or a permitted read operation.
- Review Gateway diagnostics for driver, socket, timeout, authentication, or SQL errors.
- Repeat the test after the connection has been closed and re-established so the result does not depend on a stale session.
Check: The intended Gateway completes a permitted database operation through the installed JDBC driver with no driver-loading, transport, authentication, or SQL error.
FAQ
Can I connect Ignition 8.0 beta without installing a JDBC driver?
Only when that Gateway already contains a compatible driver for the target database. A clean installation may require a separately downloaded JDBC driver because many drivers cannot be distributed with Ignition.
Does an Ignition upgrade keep my existing SQL driver?
The existing driver should remain in place during an upgrade. If it is missing afterward, inspect the upgrade or migration rather than treating the absence as normal clean-install behavior.
Can I run two Ignition Gateways on the same server?
Yes, when their service ports do not conflict. Inventory the assigned ports and verify which Gateway interface you opened before installing its driver or database connection.
Does a successful port test prove the Ignition SQL connection works?
No. It proves only that the Gateway host can reach the SQL listener. Complete the final verification by loading the correct JDBC driver, authenticating to the intended database, and executing a permitted database operation.