Произошла ошибка при получении нового значения RecId для таблицы.

[Poleax]

При импорте в VendTable через группу определения данных, вываливается ошибка:
Не удается распределить номера номерной серии для TableId:%1, CurrentNextVal:%2, NewNextVal:%3
Произошла ошибка при получении нового значения RecId для таблицы.

Имеем

VendTABLE
max RecId            min RecId
-------------------- --------------------
8000899343550730975  -7784995058763769996

(1 row(s) affected)

В справке RecID = The range of an int64 is: [-9,223,372,036,854,775,808 ; 9,223,372,036,854,775,808] (квинтиллион )


Что посоветуете, чтоб привести RecID привести в порядок?

P.S. Ax 2009 Sp1

[Poleax]

Ранее был класс SysRecIdRepair (Как выполнять дефрагментирование RecID), в АОТ его нет.

+ aEremenko: Дефрагментация RecID

Quote:

Дыры в нумерации RecID могут возникнуть, например, вследствие импорта данных, удаления и последующего импорта. Таким образом, при первом импорте был выделен пул номеров для записей, при удалении записей этот пул не восстанавливается, нумерация для последующего импорта продолжит ряд с последнего значения выделенного ранее RecID. Образовалась дыра в нумерации, когда записей нет, а номера задействованы. Проблема в том, что количество номеров конечно.

Теперь какие классы используются для дефрагментации RecID?

[mazzy]

Quote:

Originally Posted by Poleax

При импорте в VendTable через группу определения данных, вываливается ошибка:
Не удается распределить номера номерной серии для TableId:%1, CurrentNextVal:%2, NewNextVal:%3
Произошла ошибка при получении нового значения RecId для таблицы.

было такое же в таблице LedgerBalancesTrans.
почему-то дошло до максимума. то ли глюк, то ли еще.

я очистил таблицу (эта все равно чистится)
и сбросил счетчик в SystemSequences для этой таблицы в 1.

но почему дошло до максимума - загадка.

[mazzy]

Quote:

Originally Posted by Poleax

Теперь какие классы используются для дефрагментации RecID?

никакие.

[Poleax]

Quote:

Originally Posted by mazzy

было такое же в таблице LedgerBalancesTrans.
почему-то дошло до максимума. то ли глюк, то ли еще.

я очистил таблицу (эта все равно чистится)
и сбросил счетчик в для этой таблицы в 1.

но почему дошло до максимума - загадка.

Спасибо. Осталось найти алгоритм сброса счетчика в SystemSequences

Однако имеем

PHP Code:

select TOP 10 SD.Name, NEXTVAL, MAXVAL 
from SYSTEMSEQUENCES as ss
    join SqlDictionary as sd on (ss.TABID = sd.TABLEID AND sd.ARRAY =0)
order by NEXTVAL desc 


Name                                     NEXTVAL              MAXVAL
---------------------------------------- -------------------- --------------------
CUSTTABLE                                9223372036854775806  9223372036854775807
VENDTABLE                                9223372036854775806  9223372036854775807
VENDBANKACCOUNT                          5899128042471217842  9223372036854775807
CUSTBANKACCOUNT                          4215181910838106837  9223372036854775807
INVENTTRANS                              67646597533403       9223372036854775807
LEDGERJOURNALTABLE                       53435931095402       9223372036854775807
LEDGERJOURNALTRANS                       53057020090124       9223372036854775807
NUMBERSEQUENCELIST                       1333370117650        9223372036854775807
PURCHLINE                                1079295926979        9223372036854775807
NUMBERSEQUENCEHISTORY                    724040783648         9223372036854775807

(10 row(s) affected)

[Logger]

В классе импорта была ошибка. Кажется в случае если взведена галка резервирования кодов записей - аксапта могла глючить, сдвинуть счетчик recId-ов для таблицы далеко вперед (по крайней мере в трешке было именно так).

Судя по приведенным вами значениям (примерно 2^63) есть подозрение что счетчик съехал не вперед, а назад, в область отрицательных значений. Возможно в коде инкрементации счетчика recid в классе импорт ошибка с приведением типов, т.е. значение явно съехало не в большую сторону, а в меньшую.

[Poleax]

Quote:

Originally Posted by Logger

Судя по приведенным вами значениям (примерно 2^63) есть подозрение что счетчик съехал не вперед, а назад, в область отрицательных значений. Возможно в коде инкрементации счетчика recid в классе импорт ошибка с приведением типов, т.е. значение явно съехало не в большую сторону, а в меньшую.

Немного есть :

PHP Code:

print 'CUSTTABLE'
select max(recid) as [max RecId], min(recid) as [min RecId] from CUSTTABLE 
print 'VendTABLE'
select max(recid) as [max RecId], min(recid) as [min RecId] from VendTABLE 
print 'CUSTBANKACCOUNT'
select max(recid) as [max RecId], min(recid) as [min RecId] from CUSTBANKACCOUNT
print 'VENDBANKACCOUNT'
select max(recid) as [max RecId], min(recid) as [min RecId] from VENDBANKACCOUNT 


CUSTTABLE
max RecId            min RecId
-------------------- --------------------
1678119797343299707  5637145098

(1 row(s) affected)

VendTABLE
max RecId            min RecId
-------------------- --------------------
8000899343550730975  -7784995058763769996

(1 row(s) affected)

CUSTBANKACCOUNT
max RecId            min RecId
-------------------- --------------------
4215181910838106677  5637145082

(1 row(s) affected)

VENDBANKACCOUNT
max RecId            min RecId
-------------------- --------------------
2529026363488911603  5637145341

(1 row(s) affected)

[Poleax]

Quote:

Originally Posted by mazzy

и сбросил счетчик в SystemSequences для этой таблицы в 1.

Уточнение: В самой таблице [dbo].[SYSTEMSEQUENCES], при остановленном AOS, на SQL Server в БД ручками правим значение в поле NEXTVAL ?

Или используем более "элегантный" способ для выставления следующего RecID для таблицы?

[Poleax]

Quote:

Originally Posted by mazzy

но почему дошло до максимума - загадка.

http://erpkb.com/Axapta/RecId

Quote:

«Кстати, насчет дырок. Одна из причин их появления – каждый AOS (а так же тольстый клиент и клиент в 2-х звенке) резервирует под себя определенное кол-во recId (для уменьшения обращений к б/д при добавлении новых записей). При его перезагрузке это резервирование сбрасывается и выбирается новый диапазон при загрузке.»
.....................
Работает AXAPTA с этой таблицей следующим образом:
При вставке первой записи в новую компанию система AXAPTA добавляет в таблицу System Sequences? запись. В поле DATAAREAID устанавливается значение равное идентификатору компании, а в поля MINVAL и NEXVAL записывается единица.
Сразу после этого система AXAPTA берет лот номеров (лот в данном случае это – несколько подряд идущих номеров, AXAPTA берет 25). И записывает в поле NEXTVAL следующий свободный номер – 26.
Заносит в таблицу, с которой все началось запись с RECID равным 1 и DATAAREAID равным идентификатору компании.
После того как номера в лоте заканчиваются, система AXAPTA снова читает таблицу System Sequences?, берет оттуда NEXTVAL как первый номер следующего лота. А в таблицу System Sequences? записывает значение NEXTVAL+25.

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

Это конечно про старые версии Аксапты, но "мыслится", что импорте через группу определения резервируется диапазон довольно большой, и при последующих импортах часть зарезервированны RecID теряется. И так далее и далее, в итоге упираемся в MAXVAL таблицы [SYSTEMSEQUENCES]

Посморел

PHP Code:

select RECID from CUSTTABLE
order by RECID desc 


Диапазоны забавные RecID

1680993290137317294 - 1678119797343299707 (2 шт.)
5746991225213500 - 5746991225213520 (~ 200 шт.)
2873498431195913-2969044981147155 (~ 2000 шт. )
95552187129564- 95552187129568 (5 шт.)
132356740849-132356740883 (~ 100 шт.)
12486884666 - 12486884676 (10 шт.)
7349605052 (1 шт.)
5637145098 - 6207987332 (~ 15 шт.)

Записей в CUSTTABLE всего 17 146 шт.

Каком образом выбирается диапазон RecId, ну просто

[mazzy]

руками. nextval.
можно и не из EnterPrise Manager, а из аксапты. только надо зайти в компанию Dat.

[mazzy]

Quote:

Originally Posted by Poleax

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

но не квинтилионы же...

[Ivanhoe]

Quote:

Originally Posted by mazzy

руками. nextval.
можно и не из EnterPrise Manager, а из аксапты. только надо зайти в компанию Dat.

Если не ошибаюсь, после этого надо AOS перегрузить (в 4.0 точно требуется).

[Poleax]

Quote:

Originally Posted by mazzy

но не квинтилионы же...

конечно, конечно

[fed]

Переполнение recid - это не ошибка, а закономерное последствие импорта данных.
Если у тебя при импорте не стоит галочка Comress RecIds, то система вытаскивает из файла с импортом данных минимальный и максимальный recid таблицы в исходной БД и резервирует в новой БД numRecIdsToReserve=MaxOldRecId-MinOldRecId. Скажем, у тебя есть две копии БД. Боевая БД,с vendTable.recid от 1 до 2000 и реальным числом записей в 1800 (200штук в разное время удалили). Ты эту базу копируешь на полигон, как-то там правишь данные в vendTable, потом эскпортируешь данные в файл и из файла импортируешь в боевую БД. В боевой БД при импорте, будет зарезервировано (2000-1)=1999 записей и счетчик recId в systemSequences перескочит с 2001 на 4000. При этом новые recId импортируемых записей будут рассчитываться как OldRecId+2001.
Делается это для того, чтобы убыстрить импорт. В том случае если в том же файле экспорта найдутся данные другие таблиц, ссылающиеся на ventTable.recId, то эти ссылочные поля будут автоматически пересчитаны по тому же алгоритму.
Если галочку compresss RecIds включить, то система будет вести во временных таблицах (со всеми вытекающими последствиями) карту соответствия старых и новых recId и в конце импорта запускать процедуру sysImport.recIdSimpleUpdate(), которая замещает все ссылки по recId на новые значения recId. Это отнимает много времени.

Если же ты будешь регулярно повторять трюк с копированием БД на полигон, а затем перекидкой данных из полигона на рабочую БД с помощью стандартного экспорта/импорта без сжатия RecId, то каждая такая операция будет приводить к удвоению максимального recId в таблице, и спустя 53 подобных операции, 64 разряда переполнятся.

То есть - переход на 64битные recId в новых версиях аксапты, позволил решить проблему только исчерпания recId для часто обновляющихся таблиц (таких как reqTrans или recTransCov, в общем таблиц из которых часто удаляют и заново вставляют данные). Проблему импорта этот переход не решил, а только слегка снизил (ровно на 32 импорта )

[mazzy]

Quote:

Originally Posted by fed

Переполнение recid - это не ошибка, а закономерное последствие импорта данных.

но у меня то импорта не было! а переполнение - было.

[DSA]

fed совершенно верно отметил о импорте и галке compess RecIds.
Однако есть еще одно стечение обстоятельств приводящие к переполнению RecId и, более того, к AOS crash. По-крайней мере я встречал такие "чудеса" мин. на 2-х проектах (AX 2009 SP1 RU3 & RU4).

Если в пользовательских настройках включен SQL-Trace, например Long queries с сохранением в таблицу, и в контексте такого пользователя вызывается код с insert_recordSet, то у кернела сносит крышу и происходит глюк с RecId. Что особо неприятно - AOS валится.

SYSTEMSEQUENCES лечится в таком случае напрямую в SQL.

[mazzy]

Quote:

Originally Posted by DSA

Если в пользовательских настройках включен SQL-Trace, например Long queries с сохранением в таблицу, и в контексте такого пользователя вызывается код с insert_recordSet, то у кернела сносит крышу и происходит глюк с RecId. Что особо неприятно - AOS валится.

опаньки... да, у меня включен.

[DSA]

Quote:

Originally Posted by mazzy

опаньки... да, у меня включен.

Аккуратно с SQL-Trace в живой системе.

[Poleax]

Спасибо Всем, много полезных ответов.
Вопрос закрыт.

P.S. http://axforum.info/forums/blog.php?b=247

[mazzy]

Quote:

Originally Posted by DSA

Аккуратно с SQL-Trace в живой системе.

предельно.