База знаний ERP: Axapta/ Rec Id ...

Начало | Index | Changes | Comments | Users | Registration | Login  Password:  
 

Раздел: Программирование>Работа С Базой Данных


Contents

Rec Id – целое поле во всех таблицах для однозначной идентификации записи. Может быть отрицательным. Его значение может измениться результате импорта/экспорта. см. также Номерные Серии


В Ax30 Rec ID 32-битное в Ax40 — 64 битное (см Palle Agermark's WebLog : There is a new Record ID in town)


Tip: How to renumber your RecId's — как перенумеровать Rec Id


Про дырки в нумерации:
«Кстати, насчет дырок. Одна из причин их появления – каждый AOS (а так же тольстый клиент и клиент в 2-х звенке) резервирует под себя определенное кол-во recId (для уменьшения обращений к б/д при добавлении новых записей). При его перезагрузке это резервирование сбрасывается и выбирается новый диапазон при загрузке.»

Rec Id на временных таблицах


Нумерация для каждой временной таблицы (в том числе и тех, которые сделаны временными через вызов setTmp()) начинается с константы и возрастает на некоторую дельту (0x30) в рамках времени жизни табличной переменной. Если, к примеру, создать одновременной две одинаковые табличные переменные и вставить в каждую из них записи, то Rec Id у них будет одинаковый в соответствующих строках

недостатки связи по Rec ID


RECID при экспорте/импорте восстанавливаются.
Однако бывают в этом алгоритме глюки, если у тебя два поля с RECID и/или ты включаешь/исключаешь твою таблицу в коллекцию.


Нумерация по Rec Id идет в каждой компании независимо, следовательно, если есть завязка по Rec Id в одной компании, то она будет бессильна в другой... то же самое с добавление таблиц в виртуальные компании... Импорт через CVS?, тереяет ссылки по Ref Rec Id?, которые умеет восстанавливать bin импорт... т.е. приходится парами импортировать таблицы. Дефрагментация Rec Id может убить связи, если они не унаследованы от Ref Rec Id?. Если Вы убили-завели заново, допустим, поставщика, то все данные связанные поедут (Альтернативный адрес, например). Да много примеров было – все не упомнить.



/Надо Перевести:

/Сырьё?


В поле Data Area Id? хранится идентификатор компании, к которой принадлежит данная запись в нашем случае это: «Hld», «Msk», «Pit» и «Tvr». В поле Rec Id хранится порядковый номер записи, который уникален во всех записях, принадлежащих одной компании во всех таблицах. Таким образом, сочетание этих полей дает уникальный ключ, который мы и будем применять.
Здесь необходимо знать о правилах присвоения значения поля Rec ID. Axapta не пользуется никакими сервисами базы даных для вычисления нового номера в этом поле. Вместо этого она ведет таблицу System Sequences? следующей структуры:


Имя столбца Тип  Значение по умолч. NULL Описание столбца.
ID NUMBER(10) 0 NOT
NEXTVAL NUMBER(10) 0 NOT  Начало следующего пула номеров
MINVAL NUMBER(10) 0 NOT  Минимальный номер
MAXVAL NUMBER(10) 0 NOT  Максимальный номер
CYCLE NUMBER(10) 0 NOT  Номера по кругу
NAME VARCHAR2(20) ' ' NOT  Наименование последовательности
TABID NUMBER(10) 0 NOT
DATAAREAID VARCHAR2(3) 'dat' NOT  Идентификатор компании
RECID NUMBER(10) NOT  Номер записи

Работает AXAPTA с этой таблицей следующим образом:

  1. При вставке первой записи в новую компанию система AXAPTA добавляет в таблицу System Sequences? запись. В поле DATAAREAID устанавливается значение равное идентификатору компании, а в поля MINVAL и NEXVAL записывается единица.
  2. Сразу после этого система AXAPTA берет лот номеров (лот в данном случае это – несколько подряд идущих номеров, AXAPTA берет 25). И записывает в поле NEXTVAL следующий свободный номер – 26.
  3. Заносит в таблицу, с которой все началось запись с RECID равным 1 и DATAAREAID равным идентификатору компании.
  4. После того как номера в лоте заканчиваются, система AXAPTA снова читает таблицу System Sequences?, берет оттуда NEXTVAL как первый номер следующего лота. А в таблицу System Sequences? записывает значение NEXTVAL+25.

Таким образом AXAPTA решает две проблемы – каждый пользователь ведет свой лот номеров RECID и значения этого поля не пересекаются, второе – пользователь (вернее его приложение) обращается к таблице System Sequences? один раз на 25 операций вставки и таким образом не возникает ожидания из-за обращения всех к этой таблице.


In Dynamics AX, recId is assigned according to the nextVal (ID -1, name SEQNO) of System Sequence? table. But the next value of Rec Id is not always retrieved from the table, and it is cached in client machine’s memory. In AX3.0, the default cache size is 25.
Developers can change the default cache size using System Sequence? class:
In the startupPost method of Application class, you can add the following code:

SystemSequence SystemSequence;   
    …
 
    SystemSequence = new SystemSequence();
    SystemSequence.setCacheSize(30);

As a result, recIDs are drawn in sets of 30. That also means that the next value of System Sequence? table will be increased by 30 each time.


In AX 4.0, recIds will be generated unique per table instead of per company.
So for each table, there will be a nextVal (ID -1, name SEQNO) in System Sequence? table. The cache size for recId allocation is increased to 250. And AX 4 does not allow changing cache size for recId allocation anymore.



Assegnare Recid a una Tabella manualmente


MyTable xyz;
SystemSequences obj;
;
obj = new SystemSequences();
obj.SuspendRecIDs(tablenum(MyTable)); 
MyTable.overwriteSystemFields(TRUE); // dont know if this is required 
MyTable.clear;
MyTable.RecID = 4711;
...
MyTable.insert; 
obj.removeRecIDSuspension(tablenum(MyTable));

/См Также

/Ax Forum:


 
There are no files on this page.[Display files/form]
There is one comment on this page. [Display comments/form]