Приветствую.
Вопрос заключается в следующем: работа через ODBC интерфейс с БД под управлением Firebird. Обязательно ли перед освобождением дескриптора SQL выражения (SQLFreeHandle(SQL_HANDLE_STMT, qSel)) предварительно закрывать курсор функцией SQLCloseCursor, который как указано в MSDN автоматически создается при исполнении выражения функциями SQLExecute или SQLExecDirect. Или же курсор будет корректно закрыт автоматически.
А вообще может кто сталкивался с подобной проблемой, может не там копаю — подскажите пожалуйста, кто чем может :
Visual C++ 6, ODBC API, Firebird диалект 3, обращения к БД из разных потоков синхронизируюся с помощью мьютексов, однако при попытке сделать дисконнект, а затем разрушить хендлы connection и environment происходит зависание программы, причем судя по детальным собственным логам намертво — вместе со всеми дочерними потоками и динамимески подключенными DLL.

ЗЫ: Уже четвертый форум — ни одного разумного ответа, кроме забить на ODBC в обмен на компоненты прямого доступа
Замена пока не катит

Здравствуйте, Tek, Вы писали:

Tek>ЗЫ: Уже четвертый форум — ни одного разумного ответа,

Буду первым

Tek>кроме забить на ODBC в обмен на компоненты прямого доступа

Для начала, перед тем как делать громкие заявления — "уйду на компоненты прямого доступа", перечисли средства доступа к FB, обеспечивающие поддержку многопоточных приложений

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>перечисли средства доступа к FB, обеспечивающие поддержку многопоточных приложений

IBObjects к примеру. (ее кстати мне и советовали, плюс к остальному)
Но это все фигня — никуда мы не пойдем — это было не громкое заявление а крик души
Нет времени переделывать, по-этому и ищется решение проблемы или обхода.

Здравствуйте, Tek, Вы писали:

КД>>перечисли средства доступа к FB, обеспечивающие поддержку многопоточных приложений

Tek>IBObjects к примеру.

Реально? То есть я, через эти компоненты, могу без напрягов работать с одним подключением из разных потоков?

Не верю (с) Станиславский.

Здравствуйте, Коваленко Дмитрий, Вы писали:


КД>Реально? То есть я, через эти компоненты, могу без напрягов работать с одним подключением из разных потоков?

КД>Не верю (с) Станиславский.

Смотря что понимается "без напроягов" как бы то нибыло синхронизацию последовательного доступа к таблицам все-таки желаетльно использовать. Причем делать это ручками. С такой точки зрения — да, напряги есть, вот только что-то я не встречал четко работающих библиотек доступа к БД, не требующих явной синхронизации.
Точнее для бытовых задач — и BDE — выше крыши, для нашей как оказалось подобных средств недостаточно.

Здравствуйте, Tek, Вы писали:

КД>>Реально? То есть я, через эти компоненты, могу без напрягов работать с одним подключением из разных потоков?

КД>>Не верю (с) Станиславский.

Tek>Смотря что понимается "без напроягов" как бы то нибыло синхронизацию последовательного доступа к таблицам все-таки желаетльно использовать. Причем делать это ручками.

Ну, логический уровень твоего приложения находится вне компетенции компонент доступа. Без напрягов — это когда я пишу многопоточный код и меня напрягает задача, а не инструменты, с помощью которых я решаю эту задачу.

Tek> С такой точки зрения — да, напряги есть, вот только что-то я не встречал четко работающих библиотек доступа к БД, не требующих явной синхронизации.
Я тоже

Приходится пользоваться своими игрушками.

Tek>Точнее для бытовых задач — и BDE — выше крыши,

Tek>для нашей как оказалось подобных средств недостаточно.
Ты не одинок

Здравствуйте, Коваленко Дмитрий

Спасибо за моральную поддержку, это тоже очень важно.
Жаль только на первоначальный вопрос я опять-таки не получил ответа

Версия сервера какая?
А так же версия клиента и одбс?

Я, как-то сталкивался с подобным зависоном на Delphi + IBX при использовании событий сервера.
Там был баг в клиентской либе.
Всё решилось, когда клиента взяли от 2ки.

Здравствуйте, Tek, Вы писали:

Tek>Жаль только на первоначальный вопрос я опять-таки не получил ответа

здесь

Здравствуйте, Tek, Вы писали:

Tek>Приветствую.
Tek>Вопрос заключается в следующем: работа через ODBC интерфейс с БД под управлением Firebird. Обязательно ли перед освобождением дескриптора SQL выражения (SQLFreeHandle(SQL_HANDLE_STMT, qSel)) предварительно закрывать курсор функцией SQLCloseCursor, который как указано в MSDN автоматически создается при исполнении выражения функциями SQLExecute или SQLExecDirect. Или же курсор будет корректно закрыт автоматически.

Чей ODBC драйвер для FB? EasySoft, Gemini, родной c SourceForge ?

Формально, курсоры (да и вообще, ресурсы) должны освобождаться автоматически. Но все зависит от реализации.