SQLConnect fails with passwords containing a closing curly brace

[slabko]

When calling SQLConnect with a password that contains a closing curly brace (}), the driver throws the following error:

1:[HY000][1][unixODBC]';' expected

This occurs because the driver constructs a connection string that wraps every value in curly braces, e.g.:

DSN={your dsn name};Username={your_user_name};Password={your_password}

If the password includes a closing curly brace, the connection string becomes unparsable.

However, the driver works correctly with such passwords when using SQLDriverConnect, as long as the password is not wrapped in curly braces, which is not always possible for complicated passwords, for example the ones that contain semicolons.

This issue could be resolved by introducing an escape sequence for curly braces. For example, Microsoft uses double braces as escape sequences: {{ for { and }} for }. Currently, the driver does not support any escape sequence for braces.

Implications:

Most applications, such as Power BI, do not use SQLConnect; instead, they construct the entire connection string and use SQLDriverConnect. In this case, a password containing a } character is not an issue. It only becomes problematic when the password contains both a } and either a ; or a space. This is because ; forces the application to wrap the password in curly braces, e.g. {My; Pass}). If the password also contains a }, the driver—lacking support for escape sequences for closing curly braces—cannot determine where the password ends in the connection string.

Configuration

Environment

• Driver version: 1.3.3.20250317
• OS: Windows, Linux, MacOS

ClickHouse server

• ClickHouse Server version: 24.3.18.7

[laeg]

@slabko does this issue affect all passwords with special chars?

[slabko]

Not sure if I understand your question.

In the worst-case scenario, it affects all passwords containing }. However, some applications use APIs or wrap passwords in such a way that this issue is avoided. Power BI is an example of this happy case - it connects just fine with } in the password, as long as the password does not also contain a space or a semicolon.

[laeg]

I guess my question(s) is:

• Do we have a test that checks that if a password contains all special characters it passes?
• if not, do we need to broaden the scope of this issue to cover that.