cancel
Showing results for 
Search instead for 
Did you mean: 
Get Started Discussions
Start your journey with Databricks by joining discussions on getting started guides, tutorials, and introductory topics. Connect with beginners and experts alike to kickstart your Databricks experience.
cancel
Showing results for 
Search instead for 
Did you mean: 

Databricks JDBC URL fails when no space is used

nikita_w
New Contributor

Hi,

I am facing an issue while testing a Databricks JDBC connection and would like to know if this is expected behavior from the Databricks JDBC driver.

When I provide the full JDBC URL with all properties in a single string and do not add a space, the connection test fails.

Example JDBC URL (dummy values):

jdbc:databricks://example-databricks.cloud:443;httpPath=/sql/1.0/warehouses/warehouse123;AuthMech=3;transportMode=http;

During connection test, I see these errors:

  • Multiple entries with same key: authmech=3 and authmech=3
  • Multiple entries with same key: transportmode=http and transportmode=http

If I change the formatting (for example, add a space or adjust how properties are passed), the connection test works.

I would like to understand: Is this error generated by the Databricks JDBC driver?
Does the driver require a specific format or delimiter when parsing properties?
Is a space required between the JDBC URL and properties, or should this URL work as it is?
Is this behaviour expected, or should applications handle it before passing the URL to the driver?

Thanks in advance.

1 REPLY 1

Louis_Frolio
Databricks Employee
Databricks Employee

Hi @nikita_w ,

Short answer: no, the Databricks JDBC driver does not require spaces in the URL. Your URL is syntactically valid.

The official format is:

jdbc:databricks://<server-hostname>:<port>;[property1]=[value];[property2]=[value];...

Semicolons are the delimiter. Property names are case-insensitive. No spaces needed, and none of the official examples rely on them.

The duplicate key message ("Multiple entries with same key: authmech=3 and authmech=3") is the real clue here. That error pattern is characteristic of code that builds a map of key-value pairs and rejects duplicates (think Guava ImmutableMap.Builder). It means the properties are being parsed and applied twice.

This almost certainly lives in whatever client tool or framework you're using to test the connection, not in the Databricks JDBC driver itself. Here's the typical sequence:

  1. You pass a full JDBC URL string with properties embedded (AuthMech, transportMode, etc.).
  2. Your client tool parses the URL and extracts those recognized properties into its own Properties object.
  3. The tool passes both the raw URL string and the extracted Properties object to the driver.
  4. The driver parses the properties from the URL string again.
  5. When the two sets merge, each property appears twice, and the duplicate key check fails.

That also explains why "adding a space" appears to fix it. The space likely breaks your client tool's URL parser just enough that it stops extracting those properties on its own, leaving only the driver to handle them. No more duplicates, connection works. It's a workaround, not a real fix.

To actually resolve this, a few options:

Split the URL and properties (recommended approach per the docs):

String url = "jdbc:databricks://example-databricks.cloud:443";
Properties p = new Properties();
p.put("httpPath", "/sql/1.0/warehouses/warehouse123");
p.put("AuthMech", "3");
p.put("transportMode", "http");
Connection conn = DriverManager.getConnection(url, p);

If you prefer embedding everything in the URL, check whether your client tool is also setting the same keys in a separate properties or advanced settings pane. Remove the duplicates from one place or the other.

If you can capture a full stack trace, that will tell you definitively whether the exception originates in the Databricks driver JAR or in your client library.

Bottom line: the URL you showed is valid, the driver does not require spaces, and the duplicate key error is coming from whatever layer is constructing or normalizing the connection properties before they reach the driver. Fix it there.

Cheers, Lou