pastorВсе вышесказанное имеет смысл только для локального подключения.
Если сервер БД - одно, а сервер телеметрии - другое, то смысл распараллеливать есть.
смыслы бывают разными. я не говорил, что "нельзя распараллеливать вставку". Можно, конечно, но по сравнению с 1 коннектом она будет или такая же (суперсервер), или хуже (классик и суперклассик).
Просто иногда у людей витают какие-то идеи, не обусловленные практической необходимостью.
Dorin MarcociТак будет только фиксация изменений без старта другой транзакции (что я думал непростая операция).
retaining - это старт новой транзакции с сохранением "контекста" предыдущей. Нельзя стартовать транзакцию без ее старта.
Dorin Marcociбыли сделаны оптимизации по CommitRetaining и что можно держать сколько угодно транзакцию открытой.
не припоминаю такого, совсем. На текущий момент, начиная с InterBase 6.0, только один тип транзакции можно держать бесконечно открытой - read read_committed.

Dorin Marcociтолько ставки, лучше read commited version? или по барабану.
похоже, начинается толстый троллинг. read read_committed - читающая транзакция, никакие вставки в ней невозможны (разве что в гтт).

DBConstructorconcurrency+read_committed"
эта комбинация - ахинея. а если вопрос вообще, про изолированность транзакции для вставки - так какая разница???

Dorin MarcociПросто я из делфей, почти везде видел UnPrepare при Transaction.Destroy;
я вижу несколько с другой стороны - из дельфей, на 100 коннектах десятки тысяч prepared-запросов, не привязаных к транзакциям. Привязаных - штук 150.
Как-то так. Так что исходники используемых компонент надо проверять.
Возможно, что-то вроде IBSQL.Transaction:=nil; как раз вышеописанное и дает.

Смотрю TIBTransaction.Destroy - там для привязаных запросов вызывается SQLObjects[i].DoTransactionFree, которая пустышка с вызовом события, а потом RemoveSQLObjects, где тупо убирается owner.
Может где-то в недрах базовых классов что-то вызывается, но сильно сомневаюсь, по вышеуказанным причинам (проверить можно, но дельфю не хочу запускать).
Достаточно глянуть в mon$statements своей "системы на дельфях", и посмотреть на количество запросов, у которых mon$transaction_id = 0 и у которых > 0.

Так что в FB API лезть, как мне кажется, совсем не обязательно.

Dorin Marcociлучше бы требовали database_handle вместо transaction_handle в isc_dsql_prepare.
запросу делается prepare в транзакции, а не в воздухе.

DBConstructorподготовленный запрос привязывается к соединению с БД и может выполнятся
фиг знает, что он имел в виду. кстати, а сейчас это не так?