Формирование RecId при вставке в таблицу AX из SQL Server

[Hyper]

Создается таблица в AX, вставка в которую будет происходить только сторонними средствами (скорее всего DTS). Планируется изменение одного поля (Status) в созданных записях непосредственно из AX.

Разумеется, сразу озаботился необходимостью формирования RecId.

Эта тема уже поднималась 8 лет назад, но у предложенного решения было существенное ограничение: требовалось передавать параметры во внешнюю программу.

Три года назад был предложен следующий код:

Цитата:

Сообщение от oip

-- Генерация RecId. На выходе не 0 если всё Ok и 0, если что-то не так
-- Входные параметры: код компании и шаг
-- Пример: exec AX_GETRECID 'dat', '25'

CREATE PROCEDURE [dbo].[AX_GETRECID] (@dataAreaId VARCHAR(3), @hop INT)
AS
SET NOCOUNT ON
DECLARE @RecID INT
SET @RecID = NULL
UPDATE SYSTEMSEQUENCES SET  @RecID = A.NextVal,
    NextVal = A.NextVal + @HOP
FROM SYSTEMSEQUENCES A WHERE A.Id = -1 AND A.DATAAREAID = @dataAreaId
SELECT ISNULL(@RecID, 0) AS RecId
RETURN ISNULL(@RecID, 0)
GO

Не знаю, пробовал ли его уже кто-нибудь. Боязно снаружи менять SystemSequences.

В связи с тем, что пишут, что "в AX 2009 RecId уникален лишь для каждой таблицы, а не для базы в целом", появилась мысль: почему бы, ни на что не взирая, не авто-инкрементить RecId в данной конкретной таблице, начиная с единицы?

Это чем-то чревато? Как бы поступили вы сами?

Прошу поделиться соображениями.

[lev]

даже если автоинкриментить RecId, то все равно придется обновлять таблицу SystemSequence для Вашей таблицы. Иначе если вдруг запись добавят из самой аксапты, могут получиться накладки.

[Hyper]

Цитата:

Сообщение от lev

Иначе если вдруг запись добавят из самой аксапты, могут получиться накладки.

Риск минимален - таблица используется для импорта в AX внешних данных. Подразумевается, что хакерить из AX никто не будет.

[Wamr]

Цитата:

если вдруг запись добавят из самой аксапты

уникальный индекс по RecId и никаких если вдруг не произойдет
автоинкремент, и не мучайте ни себя ни аксапту

[DSPIC]

Цитата:

Сообщение от Hyper

Не знаю, пробовал ли его уже кто-нибудь. Боязно снаружи менять SystemSequences.

Пробовали, не бойтесь. Главное - не заблокировать таблицу SystemSequences, быстро получили новый RecId и отпустили таблицу.

Цитата:

Сообщение от Hyper

Это чем-то чревато? Как бы поступили вы сами?

Ничем, мы так и поступили.

[oip]

Да ничем это не чревато если Аксапта точно не будет сама что-либо писать в данную таблицу, а так же если данное поле recId нигде в бизнес-логике не участвует.

P.S. А вообще, можно сделать, чтобы и Аксапта могла в эту таблицу данные писать (используя suspendRecIds). Да и recId даже в пределах таблицы может быть и не уникален, если по нему уникального индекса нет. Только некрасиво это.

[glibs]

Чтобы Аксапта работала с таблицей как с родной (а иначе вопрос про RecId зайти не должен был бы), ее нужно создавать в АОТ. А если так, то автоинкремент в чистом виде сделать не получится, насколько я могу понимать.

Заполнять RecId нужно потустороней софтиной, по хорошему. Или писать триггер и следить стоб не стерся. А коли так, то просто развести диапазоны RecId, в которые может писать Аксапта, и в которые может писать потусторонняя софтина, чтобы они не пересеклись. Не совершенно, но быстро и просто. И оптимально с т.з. поддержки кода.

Для тех кто любит творить много совершенного кода и не беспокоится о стоимости его поддержки варианты были предложены...

[DSPIC]

Цитата:

Сообщение от glibs

Чтобы Аксапта работала с таблицей как с родной (а иначе вопрос про RecId зайти не должен был бы), ее нужно создавать в АОТ. А если так, то автоинкремент в чистом виде сделать не получится, насколько я могу понимать.

Заполнять RecId нужно потустороней софтиной, по хорошему. Или писать триггер и следить стоб не стерся. А коли так, то просто развести диапазоны RecId, в которые может писать Аксапта, и в которые может писать потусторонняя софтина, чтобы они не пересеклись. Не совершенно, но быстро и просто. И оптимально с т.з. поддержки кода.

Для тех кто любит творить много совершенного кода и не беспокоится о стоимости его поддержки варианты были предложены...

Я бы не делал из мухи слона. По-моему, здесь только усложнения: триггер, следить, чтобы он не стерся, развести диапазоны... Единственное, что действительно стоит отсюда добавить в верхние посты - это не связываться с хранимой процедурой и получать следующее значение RecId в той же софтине: т..е. написать метод

int64 getNextRecId(int _tableId)

>Для тех кто любит творить много совершенного кода и не беспокоится о стоимости его поддержки варианты были предложены...

Glibs, если предложишь решение по выделению RecId проще и дешевле в поддержке - ставлю пиво.

[Hyper]

Цитата:

Сообщение от glibs

Чтобы Аксапта работала с таблицей как с родной (а иначе вопрос про RecId зайти не должен был бы), ее нужно создавать в АОТ. А если так, то автоинкремент в чистом виде сделать не получится, насколько я могу понимать.

Заполнять RecId нужно потустороней софтиной, по хорошему.

Да, я имел в виду "программный" инкремент, ответственность за который несет внешняя софтина.

Цитата:

Сообщение от oip

А вообще, можно сделать, чтобы и Аксапта могла в эту таблицу данные писать (используя suspendRecIds).

Кстати, да, хорошая защита от излишне ретивых девелоперов. Перекрыть метод insert на таблице, делать в нем suspendRecIds, программное выделение RecId, super(), removeRecIdSuspenson. Таким образом даже если кто-то "случайно" вставит запись из AX, корректность RecId можно проконтролировать.
Но я все-таки склоняюсь к первоначальной идее перекрыть insert и закомментировать super().

Пока, насколько я понимаю, lev и DSPIC предпочитают использование кода, приведенного выше, а Wamr, oip и glibs согласны, что без этого можно обойтись.

[Hyper]

Цитата:

Сообщение от Hyper

Три года назад был предложен следующий код

Только обратил внимание, что код для тройки. Для AX2009 надо еще подставить TableId:

FROM SYSTEMSEQUENCES A WHERE A.Id = -1 AND A.TABID =  AND A.DATAAREAID = @dataAreaId

С утра на свежую голову решил все-таки формировать RecId с помощью SystemSequences.
Если столкнусь с трудностями, буду иметь запасной вариант (игнор SystemSequences) в виду.

Всем спасибо за советы.

P.S. Ну и @RecID должен быть BIGINT. Еще что-то пропустил?

[lev]

Цитата:

Сообщение от Hyper

С утра на свежую голову решил все-таки формировать RecId с помощью SystemSequences.
Если столкнусь с трудностями, буду иметь запасной вариант (игнор SystemSequences) в виду.

Всем спасибо за советы.

Мне кажется правильное решение

ИМХО. Если уж в программе определен механизм определения RecId, то нужно его придерживаться и при использовании внешних систем.
Что бы в будущем спать спокойно

[Владимир Максимов]

У меня вопрос. Правда, не совсем по теме

В Ax2009 записи в таблице SystemSequences могут иметь значение DataAreaId отличное от "DAT"? При каких условиях? Если не могут, то какой смысл в параметре @DataAreaId в приведенной функции?

[ZVV]

Цитата:

Сообщение от Владимир Максимов

У меня вопрос. Правда, не совсем по теме

В Ax2009 записи в таблице SystemSequences могут иметь значение DataAreaId отличное от "DAT"? При каких условиях? Если не могут, то какой смысл в параметре @DataAreaId в приведенной функции?

А что в этом плане разве чт-то поменялось по сравнеию с предыдущими версиями?
В каждой компании свой набор RecId, и соответсвенно свои записи с SystemSequences ...

[Hyper]

Цитата:

Сообщение от Владимир Максимов

В Ax2009 записи в таблице SystemSequences могут иметь значение DataAreaId отличное от "DAT"?

В AX2009 я такого не наблюдаю, но в тройке вижу разные SystemSequences.DataAreaId для разных компаний.

[AndyD]

Цитата:

Сообщение от Владимир Максимов

У меня вопрос. Правда, не совсем по теме

В Ax2009 записи в таблице SystemSequences могут иметь значение DataAreaId отличное от "DAT"? При каких условиях?

В результате использования класса SystemSequence

[Владимир Максимов]

Цитата:

Сообщение от AndyD

В результате использования класса SystemSequence

Можно пример?

[AndyD]

А разве в 2009-й recId идет в разрезе компаний?

[ZVV]

Цитата:

Сообщение от AndyD

А разве в 2009-й recId идет в разрезе компаний?

и правда, нет... не знал.

[AndyD]

Так в документации есть

    Sequence S = new Sequence("mySequence",1,100,10000);
    print S.nextval(10);           // 100 in current company (the subkey)
    print S.nextval(10);           // 110 in current company (the subkey)
    print S.nextval(1,"MMM");      // 100 in subkey "MMM"
    print S.nextval(1,"MMM");      // 101 in subkey "MMM"

Вот только subkey у меня в Rollup 7 не работает - последовательность продолжается, но запись в текущей компании регистрируется

PS Ой, класс неправильно выше назвал

[Владимир Максимов]

Цитата:

Сообщение от AndyD

Вот только subkey у меня в Rollup 7 не работает - последовательность продолжается, но запись в текущей компании регистрируется

Да вроде все работает. Просто Axapta сверяет указанное значение subkey со списком существующих компаний. Если нет совпадений, то ошибок не выдает, но запись идет в текущую компанию.