Цитата:
Сообщение от
Pandasama
выдает результаты:
5637264076
5637264327
5637264077
то есть третий резерв возвращает значение меньше чем второй
У меня возвращает корректно. Применительно к Вашему примеру последнее число было бы
5637274077
Обратите вниманием на окончание: 74077, а не 64077, как у Вас. Возможно, Вы просто невнимательно посмотрели на число в этом разряде?
Цитата:
Сообщение от
Pandasama
(чтобы не разбивать запрос на две части - подсчет количество и саму вставку)
Разбивать по любому придется.
Дело в том, что Axapta резервирует часть значение RecId. Т.е. определение значения по полю таблицы systemsequences.nextval ни о чем не говорит. Далеко не факт, что именно это значение и будет использовано в среде Axapta для генерации следующего значения. Как следствие, Вы рискуете присвоить не корректные значения RecId. Те, с которыми позже произойдет пересечение при обычной работе Axapta
Другими словами недопустимо на основании systemsequences.nextval сфоромировать RecId, а потом попросить Axapta зарезервировать NN значений. Не получится, поскольку Axapta может начать резервирование вовсе не с того значения, которое указано в systemsequences.nextval
Кроме того, с предварительным запросом во временную таблицу проще организовать нумерацию, при этом задержка по времени незначительная. У меня получается примерно так
X++:
// Этап 1 выборка во временную таблицу
if object_id('tempDB..#NewData') is not null drop table #NewData;
select
(...)
, identity(int,1,1) as RowNum
into #NewData
from (...)
// Подсчет записей. Это значение считываем в Axapta
select count(*) from #NewData
// Этап 2
// Резервирование RecId в Axapta
// И передача начального номера RecId в SQL
// Этап 3 - Вставка в итоговую таблицу
// beginRecId - переданное начальное значение
insert into MyTable
(...
,RecId
)
select
...
, #NewData.RowNum - 1 + beginRecId
from #NewData
Я использую динамическое формирование запроса в среде Axapta, поэтому временные таблицы. Если использовать хранимые процедуры SQL, то придется делать постоянные таблицы