Глюк с RecId в Ax 4.0

[npokypatop]

Господа, всем доброго вторника,
на проекте возникла небольшая проблема - Аксапта отказывается вставлять запись в таблицу, аргументируя это тем, что такая запись уже есть. Помогает только тупое удаление всех записей таблицы. Ключ в таблице - по RecId. Раньше такое было редко, да и таблицы были какие-то не очень важные.
Но сейчас Аксапта отказывается вставлять запись в SysDataBaseLog, в PrintOutTable
Ругается так:

Невозможно создать запись в ...

То есть суть проблемы ясна - Аксапта генерит неуникальный RecId...
Как это можно полечить?.. При остановке AOS это тоже проходит, но не всегда, да и это не выход

[_scorp_]

C RecId в четверке SP2 тоже ловил непонятные глюки. Например, заметил следующую закономерность - при выполнении групповой разноски журналов одним пользователем(Главная книга / Периодические операции / Разнести журналы) другие при попытке сохранить созданный журнал часто ловят ошибку от SQl-сервера на таблице LedgerJournalTable: The INSERT statament conflicted with CHECK constraint "CK__X211X__RECID__721145A6". Смотрю это ограничение ([RECID]<>(0)) на SQL сервере и не понимаю как такое могло получиться. Получается что RecId просто не выделился. Своего кода в тех областях нет вообще. Лечится само пересозданием журнала. Разбираться не было времени пока. Кто-нибудь еще сталкивался?

[Logger]

1. Попробуйте проверить табличку SystemSequences - там хранятся системные номерные серии - для recId в том числе. Возможно сбилось значение счетчика.
2. Проверьте индексы на табличке. У меня как-то был случай - создали уникальный индекс по RecId средствами БД. DataAreaID - в индексе не было. - Соответсвенно случайным образом возникал конфликт уникальности и транзакция откатывалась. При этом Аксапта выдавала левое сообщение об ошибке.

[Gustav]

Цитата:

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

То есть суть проблемы ясна - Аксапта генерит неуникальный RecId...

Откуда это известно? Она сообщает именно о такой неуникальности?

Вспомнив, что что-то этакое было у меня с таблицей PrintOutTable_Ru, порылся в своих рабочих "блогах". Нашёл вот такую тайнопись:

\Classes\PurchFormLetter_PackingSlip\writeJournal - line 6
\Classes\PrintoutTableReports_SlipsM4M7_RU\run - line 1
\Classes\PrintoutTableReports_SlipsM4M7_RU\run - line 63

"Невозможно создать запись в PrintOutTable_Ru"

И вывод: Надо искать запись с таким SalesPurchID (!!!) и удалять ее перед попыткой вставки.

Может, натолкнет на что-нибудь конструктивное...

P.S. В PrintOutTable_Ru помимо уникального ключа по RecId есть еще уникальные индексы, в которые поле RecId не входит (во всяком случае в Ax 3.0 SP4 это так).

[npokypatop]

Спасибо за совет, Gustav,
но ругается оно именно на RecId.
Замечено это было еще при разноске журналов по модулю Производство, но поскольку тогда это было в рамках обучения - меня это не очень заинтересовало (там тоже были таблицы с параметрами)
Сейчас проблема на реальном проекте - и это не все таблицы, по которым она возникает.
Если бы ошибка была в самом деле в коде, то она бы не исчезала после перезапуска АОС.
А в строке 63 метода run класса PrintoutTableReports_SlipsM4M7_RU производится именно вставка
printoutJournal.insert();
По индексам TypeSalesPurchIdLocationIdx и NumTypeIdx все в порядке. Остается только один вариант.

[npokypatop]

Цитата:

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

1. Попробуйте проверить табличку SystemSequences - там хранятся системные номерные серии - для recId в том числе. Возможно сбилось значение счетчика.
2. Проверьте индексы на табличке. У меня как-то был случай - создали уникальный индекс по RecId средствами БД. DataAreaID - в индексе не было. - Соответсвенно случайным образом возникал конфликт уникальности и транзакция откатывалась. При этом Аксапта выдавала левое сообщение об ошибке.

Спасибо, сейчас попробую