"Kovalenko Dmitry" ...
А чем для сервера должна отличаться "висящая" открытой транзакция
из-за обрыва соединения и в этом случае?
Тем, что ругается он при детаче. А значит и приложение и коннект живы.
Я вот щас напписал очередной шаблонный код
-------------
{
connection_object->Attach(....)
isc_tr_handle tr_handle=NULL
isc_start_transaction(status_vector, &tr_handle, ....)
} //деструктор connection_object будет пытаться выполнить дисконнект и обломится
И кто тут с прямыми руками ?
// Но мне не страшно - я после этого выгружу клиентскую библиотеку к едрене
матери
-------------
См. выше
Мысль о том, что детач должен ругаться на наличие открытых транзакций, конечно
правильная.
Да
Как и та, что при передаче NULL в качестве статус вектора, fbclient.dll
опрокидывает все приложение.
Нет такой мысли - одни баги
Типа пишите правильные приложения. Но что то тут очень сильно Джимом пахнет :)))
В моргскуль :)
Проблема с детачем решается исключительно построением дерева объектов, в
котором дети блокируют в памяти родителей
Нет никакой проблемы с детачем
connection <--- transaction <---- statement
и не дают их грохать раньше себя.
Вопрос - в правильных FIBPlus я могу грохнуть датабазу раньше транзакции? В нем
используются блокировки, это дело предотвращающие?
Не знаю, не пользую, но подозреваю что родители как минимум проверяют наличие
детей с хендлами и возможно грохают их сами.
Блокировки ваще не догнал - это ты о чём ?
Это я щас чисто с точки зрения "ох....вания" IB API, спрашиваю.
Ничё, попустит... :)
--
Хорсун Влад
