[BUG] Unity Catalog name duplicated in schema metadata calls under DataGrip

[crmorton]

Description

When using the Databricks JDBC Driver (OSS) in DataGrip to connect to an Azure Databricks SQL Warehouse via OAuth, double-clicking a table in the Database Explorer side panel fails to open the data viewer. DataGrip generates a localized SELECT query, but an underlying JDBC metadata or session state loop causes the driver to query a malformed, duplicated path (catalog.catalog) instead of parsing the correct schema path.

This behavior persists despite configuring ConnCatalog and forcing metadata introspection via standard JDBC channels.

Steps to Reproduce

1. Configure a DataGrip connection using Databricks JDBC Driver 3.4.2.
2. Connect to an Azure Databricks SQL Warehouse using OAuth (AuthMech=11, Auth_Flow=0).
3. Set connection parameters: ConnCatalog=ocdao_dev__slv and empty/blank default database parameters.
4. Successfully authenticate and expand the catalog tree down to a target table (e.g., ocdao_dev__slv.pracsys_ml.drivers_rtw_df_ver_4).
5. Double-click the table to view its contents.

Expected Behavior

DataGrip should either run a fully qualified query:
SELECT * FROM ocdao_dev__slv.pracsys_ml.drivers_rtw_df_ver_4 LIMIT 501;
Or successfully set the active session catalog/schema boundaries without causing internal evaluation conflicts.

Actual Behavior

DataGrip changes the context tab to ocdao_dev__slv.pracsys_ml> but the underlying connection state crashes with a SCHEMA_NOT_FOUND error because it attempts to look up ocdao_dev__slv.ocdao_dev__slv.

Generated Query in Log:

ocdao_dev__slv.pracsys_ml> SELECT t.*
                           FROM pracsys_ml.drivers_rtw_df_ver_4 t
                           LIMIT 501

Returned Exception:

[42704][1003] Operation failed with error: [no error details from server] for statement [01f1b17e-5793-1eb2-a106-cd2d481a09a3], with response [TGetOperationStatusResp(status:TStatus(statusCode:SUCCESS_STATUS), operationState:ERROR_STATE, sqlState:42704, errorCode:0, errorMessage:org.apache.hive.service.cli.HiveSQLException: Error running query: [SCHEMA_NOT_FOUND] org.apache.spark.sql.catalyst.analysis.NoSuchDatabaseException: [SCHEMA_NOT_FOUND] The schema `ocdao_dev__slv.ocdao_dev__slv` cannot be found. Verify the spelling and correctness of the schema and catalog.
If you did not qualify the name with a catalog, verify the current_schema() output, or qualify the name with the correct catalog.

Note: Writing out the exact query manually with a 3-part identifier (select * from ocdao_dev__slv.pracsys_ml.table) in a separate console completely works.

Driver & Environment Info

• Driver Version: 3.4.2 (OSS)
• Deployment: Azure Databricks
• Compute: Databricks SQL Warehouse
• Client: JetBrains DataGrip
• Authentication: OAuth User-to-Machine / Machine-to-Machine

[vikrantpuppala]

@vuanhphung please take a look at this as well

[jay-xiao446]

I was able to reproduce the issue following the description with DataGrip. And the issue stems from DataGrip. The exception is from use main submitted by DataGrip. Databricks interprets it as schema, v.s. catalog. For using catalog, the right syntax is Use Catalog main. JDBC works as expected.

Schema: https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-ddl-use-schema
Use Catalog: https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-ddl-use-catalog

Time (UTC)	Event	Evidence
2026-09-24 23:31:01	JDBC session opened with catalog main and schema default.	~/databricks_jdbc.log.0:222
2026-09-24 23:31:01	DataGrip submitted use main through the JDBC driver.	~/databricks_jdbc.log.0:401
2026-09-24 23:31:01	The Databricks SQL Warehouse rejected the command because it resolved to schema main.main.	~/databricks_jdbc.log.0:842
2026-09-24 23:31:01	DataGrip continued with SELECT t.* FROM table_name t LIMIT 501.	~/databricks_jdbc.log.0:1290
2026-09-24 23:31:07	The warehouse completed the table query.	~/databricks_jdbc.log.0:2010
2026-09-24 23:31:07	The driver received valid result metadata, including the table columns.	~/databricks_jdbc.log.0:2632
2026-09-24 23:31:07	The driver reported Result retrieved successfully.	~/databricks_jdbc.log.0:2641