The driver does not work

[alexey-milovidov]

It prints

Session ... is locked by a concurrent client.

I'm wondering how anyone can use it.

See ClickHouse/ClickHouse#54952

[mshustov]

@alexey-milovidov IIRC, you mentioned it was an incorrect usage. Could you provide more details?

[gfody]

same issue here using the odbc driver from SQL Server (CLICKHOUSEODBCW.DLL 1.02.01.35817 2022-09-09)

Code: 373. DB::Exception: Session clickhouse_odbc_6468917993997271918 is locked by a concurrent client. (SESSION_IS_LOCKED) (version 23.9.6.20 (official build))

the error is intermittent/random but seems related to server load

[mshustov]

seems related to server load

@gfody could you elaborate please?

[gfody]

seems related to server load

@gfody could you elaborate please?

while testing we noticed that the longer it takes for the queries to execute the more likely we were to hit this exception

eg

select * from openrowset('MSDASQL',
'Driver={ClickHouse ODBC Driver (Unicode)};username=...;password=...;url=http://...',
'select .... limit 100000')

testing with different numbers for limit 100000 increasing it seems to increase the odds that we'll hit the "locked by concurrent client" exception, although it really is very random. we also tested various querystring parameters in url as elsewhere it was mentioned to try setting wait_end_of_query=1 and different values for buffer_size .. the rate of this exception seemed mostly dependent on the limit or execution duration.

if we try setting session_id to some random value then we always immediately get the exception 100% of the time, eg:

select * from openrowset('MSDASQL',
'Driver={ClickHouse ODBC Driver (Unicode)};username=...;password=...;url=http://...?session_id=123456789',
'....')

OLE DB provider "MSDASQL" for linked server "(null)" returned message "HTTP status code: 500
Received error:
Code: 373. DB::Exception: Session 123456789 is locked by a concurrent client. (SESSION_IS_LOCKED) (version 23.9.6.20 (official build))

edit - I tested again with session_id in the querystring and it's not 100% of the time, just as frequent as the other cases. It seems that there are windows of time where 100% of requests will hit this exception but it's not due to any of the parameters we were testing.