the expectation when you run the query

[PavelNewsky]

For any query, ExecuteReader () does not wait for the query to complete.
And my select is about 200
seconds clickhouse, so my app does not display an empty "reader" if necessary do not use sleep(). Every time guess sleep()? Is it serious? Explain, so same should not be. When using " sql reader "with MSSQL," execute " is waiting to execute

[killwort]

I barely can understand you, sorry. If you want you could write in Russian.

This driver is fully synchronous - it always waits for data from server before returning. As for ExecuteReader - it waits for execution result and first result set (Block in CH's terminology).

[PavelNewsky]

Простите за мой плохой английский)
Проблема как раз в том, что мое приложение на c#, которые использует эту библиотеку, не ждёт завершения запроса, если он достаточно большой(уточняю это, потом что на небольших запросах все работает, естественно)

Чтобы было проще понять... Я использую ExecuteReader команды, в которой находится INSERT table1 SELECT * FROM table2 - это примерная маска команды, select'ы на самом деле сложнее. Так вот, эта команда выполняется примерно 30 секунд, но так как ExecuteReader не ждёт завершения этой команды, как я утверждаю (а также видно в отладке), на следующей команде(цепляет результат предыдущей) вылетает ошибка.

[killwort]

Соединения нельзя использовать в разных потоках (в том числе в TPL тасках), это, естественно, приводит к ошибкам.
В принципе, накладные расходы на открытие нового соединиения не велики, так что для каждого запроса можно открывать новое соединение (или использовать connection pool/object pool).

Не очень понятно как и в каком контексте вы ждёте исполнения ExecuteReader, лучше было бы прислать кусок кода, чтобы было понятнее.
И, кстати, всегда и обязательно надо считывать все result-set'ы возвращённые запросом при помощи do{...}while(reader.NextResult()), иначе непрочтённые блоки будут читаться в ответ на следующий запрос, что, опять же, приведёт к ошибке.

[PavelNewsky]

Спасибо, ваши комментарии отчасти помогли, я действительно подключался к базе с одного потока, а выполнял запросы в другом. Исправил, пришлось ещё поколдовать с таймаутами, потому что запрос все равно не успевал выполниться за какой-то дефолтный таймаут.