02.02.2017, 07:39 | #17 |
Участник
|
Да, я вчера пришел к подобной же мысли, только реализовать решил по-другому:
(чтобы не разбивать запрос на две части - подсчет количество и саму вставку) делаю заморозку выделения 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 от первого выделения Последний раз редактировалось Pandasama; 02.02.2017 в 08:40. |
|
Теги |
ax2009, recid, sql, systemsequences |
|
|