Skip to content

Tags: duckdb/duckdb-odbc

Tags

v1.4.4.0

Toggle v1.4.4.0's commit message
Update vendored DuckDB sources to 6ddac802ff

v1.4.3.0

Toggle v1.4.3.0's commit message
Fix Windows ARM64 upload to CF

v1.4.2.0

Toggle v1.4.2.0's commit message
Update vendored DuckDB sources to 68d7555f68

v1.4.1.0

Toggle v1.4.1.0's commit message
Update vendored DuckDB sources to b390a7c376

v1.4.0.0

Toggle v1.4.0.0's commit message
Update vendored DuckDB sources to b8a06e4a22

v1.3.2.0

Toggle v1.3.2.0's commit message
Update vendored DuckDB sources to 0b83e5d2f6

v1.3.1.0

Toggle v1.3.1.0's commit message
Support running an SQL file on init (1.3)

This is a backport of the PR #157 to `v1.3-ossivalis` stable branch.

This change is a counterpart of a similar functionality in DuckDB JDBC
driver added in duckdb/duckdb-java#252.

It adds support for `session_init_sql_file` connection option,
that allows to speficy the path to an SQL file in local file system,
that will be read by the driver and executed in a newly created
connection before passing it to user.

By default the file is initalized only once per database, on the first
`SQLConnect` call to this DB.

For `:memory:` connection-private DBs it effectively executed once per
connection.

In addition to the DB init, it supports executing a part of the SQL
file for every connection. It looks for the specific marker:

```
/* DUCKDB_CONNECTION_INIT_BELOW_MARKER */
```

in the SQL file. If this marker is present - everything before the
marker is executed on DB init, and everything after this marker - on
connection init.

To minimize the security impact of this change in contexts, where other
applications/processes/users can control the appending to user-specified
connection string or re-writing the specified file in local file
system, the following restrictions are added:

 - `session_init_sql_file` can only be specified in the DSN
   configuration in `.ini` file or in Windows Registry; unlike oridinary
   options, this options can NOT be used in the connection string to
   override DSN configuration
 - `session_init_sql_file_sha256=<sha56sum_of_sql_file>` option can be
   specified (also only in DSN), the file contents SHA-256 sum is
   checked againts this value
 - contents of the SQL file being executed are added to the diagnostic
   records for the `SQLConnect/SQLDriverConnect` call, when ODBC tracing
   is enabled in Driver Manager settings - the full SQL file is printed
   to the log like this:

```
<Client app name>       7cc-2300	EXIT  SQLDriverConnectW  with return code 1 (SQL_SUCCESS_WITH_INFO)
[...]
DIAG [01000] ODBC_DuckDB->SQLDriverConnect
Session init SQL:
<SQL file contents>
```

Testing: new tests added (in a separate file), they use
`SQLWritePrivateProfileString` Driver Manager API to temporary set
`session_init_sql_file` in user DSN settings. This call has some
limitations (cannot set `database` on Windows) but is confirmed to work
on CI for all platforms.

v1.3.0.0

Toggle v1.3.0.0's commit message
Update vendored DuckDB sources to 71c5c07cdd

v1.2.2.2

Toggle v1.2.2.2's commit message
Support DATE and TIME bind parameter types

Support for `DATE` and `TIME` value was lacking in
`SQLBindParameter`/`SQLExecute`. This change adds such support the
same way as `TIMESTAMP` parameters are handled.

Besides that, when fetching records with `SQLGetData` there was no
conversion from DB `TIME` type to ODBC `TIMESTAMP` type. Such
conversion for some reason does not exist in the engine. But PyODBC uses
it by always fetching `TIME` columns as `TIMESTAMP`. This conversion is
added manually.

Testing: existing test adjusted when fetching `TIME` as `TIMESTAMP`, new
test is added to cover `SQLBindParameter` with `TIMESTAMP`, `DATE` and
`TIME` types.

Fixes: #91

v1.2.2.1

Toggle v1.2.2.1's commit message
Revert "Update isql tests after duckdb/duckdb#15864"

This reverts commit 2d1d51c.

This needs to be reverted because the implementation of `AVG(INTERVAL)`
that was added in duckdb/duckdb#15864 is not included in
`v1.2-histrionicus` thus the `isql` test (that is present only in ODBC
repo) is failing on it.