[Pandasama]

Да, я вчера пришел к подобной же мысли, только реализовать решил по-другому:
(чтобы не разбивать запрос на две части - подсчет количество и саму вставку)
делаю заморозку выделения RecID
выполняю запрос
резервирую разницу между следующим RecId и фактическим RecId после вставки в таблицу
снимаю заморозку

но реализация что-то не работает:

--start
----макс. recid в таблице 5642940489, systemsequences.nextval 5642940490
--suspend
--before query
----макс. recid в таблице 5642940540, systemsequences.nextval 5642940740
----systemsequence.reserve(1) = 5642940543
--execute insert query
--after query
----макс. recid в таблице 5642945298, systemsequences.nextval 5642940740
----systemsequence.reserve(1) = 5642940544
----systemsequence.reserve(4754 {5642945245 - 5642940491 - разница между след. рекид и фактическим рекид}) = 5642940740
--removesuspend

--а теперь проверим, какой RecId будет следующий
--suspend
----systemsequence.reserve(1) = 5642940545 //будто бы не было reserve(4754)
--removesuspend

По идее, я зарезервировал 4754 RecId начиная с 5642940740 - то есть следующий номер должен быть 5642940740 + 4754
Или у меня неверные представления о работе резерва, и система не только резервирует, но ещё и по факту отслеживает вставку записей с этими RecId ?

Впрочем, с выделением ДО запроса ситуация такая же:
выделил скопом 10000 (больше реально вставляемых 4754), получил recid 5642990876, значение в systemSequence.nextVal = 5643000876
вставил запросом в таблицу
выделил ещё 1 для проверки - получил 5642980716, значение меньше стартового RecId от первого выделения