@hyaqoob @saf_dbx Your query and your connection are both fine. Error 10220 is the Databricks JDBC driver's SQLFeatureNotSupportedException, which means the tool called an optional JDBC API method the driver does not implement. It happens during data source setup, before your SQL matters at all, which is why the same query runs cleanly when you execute it in Databricks directly.

With reporting and EPM tools this is likely the transaction control. The tool calls `setAutoCommit(false)` (or `commit`/`rollback`) on the connection as part of its standard ceremony, because it assumes it is talking to a transactional database. The Databricks driver refuses those calls by default.

The driver has a documented connection property for exactly this situation. Add it to the end of your JDBC URL:

```
;IgnoreTransactions=1
```

By setting to 1, the connector ignores transaction-related operations and returns success; and setting to 0 (the default), it returns the operation-not-supported error you're seeing. So Essbase can make its transaction calls and the driver quietly accepts them instead of failing the data source creation.

Few things to consider before configuring this parameter. It does not add transaction support, it makes the driver report success for calls it did not perform. `setAutoCommit(false)`, `commit`, and `rollback` all return success and do nothing. This means few things. First, the tool believes it has transactional guarantees it does not have. If anything on that connection ever writes to Databricks, a failure halfway through a batch leaves the rows that were already written, and the tool's rollback will report success while removing nothing. Second, the setting is connection-wide, not per-query, so it applies to everything that DSN or URL is used for, including whatever someone configures on it a year from now.

For your case as described, pulling data from Databricks into Essbase, the connection is read-only and none of this may apply at all.