Test the Oracle listener from the gateway host
Confirm the gateway machine can reach the Oracle listener before debugging credentials or schema grants.
Test-NetConnection <oracle-server-name-or-ip> -Port 1521Database troubleshooting
Oracle gateway setup and troubleshooting
Diagnose Oracle Database connector setup, gateway host driver/client requirements, TNS/service names, credentials, row-operation limits, and common import validation steps.
Use this guide when
- Oracle connection test failed
- TNS/service name confusion
- Oracle works in SQL Developer but not in Power Automate
- Oracle row actions need a gateway-ready test fixture
Prerequisites
- Oracle Database is reachable from the gateway machine on the listener port, often 1521.
- The Oracle client/provider required by the connector is installed and configured on the gateway machine, unless your gateway version supports a built-in option that you have enabled.
- The Power Automate user can access the target schema, tables, views, and stored procedures.
- Tables used by row operations have single-column primary keys where required.
Fast checks before you debug
- Oracle client software must be on the gateway host, not only on the developer workstation.
- Service name, SID, and TNS alias are different concepts; test the same one you use in Power Automate.
- Composite keys and stored procedure output semantics may not map cleanly to Power Automate row actions.
- Restart the gateway after Oracle client/provider changes.
Step-by-step diagnostics
Test with Oracle tooling from the gateway host
Use SQL*Plus, SQLcl, or another Oracle client installed on the gateway machine. Test the same service/SID/TNS alias and user that Power Automate will use.
sqlplus <user>/<password>@//<server>:1521/<service_name>tnsping <tns-alias>Verify Oracle client/provider configuration
If Power Automate cannot load the Oracle provider, install/configure the required 64-bit Oracle client or gateway-supported provider option on the gateway host, then restart the gateway.
Restart-Service PBIEgwServiceCheck table key and schema access
For generated row actions, validate the target table has the key shape expected by the connector and that the user has access to the schema objects.
SELECT table_name FROM all_tables WHERE owner = UPPER('<schema>');SELECT cols.table_name, cols.column_name FROM all_constraints cons JOIN all_cons_columns cols ON cons.constraint_name = cols.constraint_name AND cons.owner = cols.owner WHERE cons.constraint_type = 'P' AND cons.owner = UPPER('<schema>');Common errors and fixes
- Likely cause
- SQL Developer used its own client configuration or was run from a different machine than the gateway.
- Fix
- Run SQL*Plus/SQLcl from the gateway host using the same service name and credentials.
- Likely cause
- tnsnames.ora or Oracle network configuration is not available to the gateway runtime.
- Fix
- Use direct host:port/service syntax or configure TNS_ADMIN/tnsnames for the gateway host and restart the service.
- Likely cause
- The table uses composite keys or lacks a connector-friendly primary key.
- Fix
- Use a single key table/view design, a stored procedure, or a reviewable HTTP/custom connector mapping for complex cases.
Power Automate connection fields
| Field | Use this value |
|---|---|
| Server | Oracle host, TNS alias, or connection string shape accepted by the connector. |
| Username | Oracle user with access to the schema objects used by the flow. |
| Gateway | Gateway host with Oracle client/provider installed and configured. |
| Connector | Oracle Database connector, usually Premium in Power Automate. |
Validation checklist
- Port 1521 or the configured listener port is reachable from the gateway host.
- Oracle client/provider is installed and loaded by the gateway runtime.
- SQL*Plus/SQLcl succeeds from the gateway host with the same connection string.
- Schema, table, and key requirements are verified for generated actions.
- Stored procedure/native query behavior is tested separately when used.