Connection-string keys borrowed from other vendors that the driver accepts, plus keys it silently ignores so a connection string copy-pasted from another tool is not rejected.
<vendor-key>=<value>
## Why aliases Users copy connection strings between drivers. Forcing them to rewrite from scratch is hostile. The Delta Forge driver accepts the most common vendor vocabularies and maps them to its native keys before processing. ## Recognised aliases | Vendor key | Maps to | Notes | |---|---|---| | `HOST` plus `PORT` | `Server=http://HOST:PORT` | Synthesised only when `Server=` is empty | | `DATABASE` / `CATALOG` | `Database` | | | `SCHEMA` | `Schema` | | | `Authentication` | `AuthMode` | Tableau / Databricks | | `AuthMech` | `AuthMode` | Spark / Hive | | `AccessToken` | `Token` | Snowflake / Databricks | | `OAuthToken` | `Token` | Snowflake | | `User` / `User ID` | `Uid` | SQL Server | | `Password` | `Pwd` | Generic | | `LoginTimeout` | `ConnectionTimeout` | SQL Server | | `Connect Timeout` | `ConnectionTimeout` | SQL Server | | `ProxyHost` plus `ProxyPort` | `HTTPProxy=http://Host:Port` | Generic | ## Silently tolerated (no-op) These keys are present in connection strings copied from other tools but have no Delta Forge equivalent. The driver accepts them without error so the connection still works: `DRIVER`, `DSN`, `TRUSTED_CONNECTION`, `APPLICATIONINTENT`, `LOCALE`, `LANGUAGE`, `HTTPPATH`. The behaviour each implies on its origin platform is not emulated; the key is simply consumed and discarded. ## Unrecognised keys If the parser does not recognise a key, it accepts the value silently. This means a future BI tool's exotic key will not break a working connection.
# SQL Server vocabulary
Driver={DeltaForge ODBC Driver};Server=https://df.example.com;LoginTimeout=30
# Databricks / Snowflake token vocabulary
Server=https://df.example.com;HOST=df.example.com;PORT=9224;OAuthToken=df_pat_...