Переполнение RecId в компании DAT AX 2.5

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

В ближайшие полгода в нашей системе ожидается "зацикливание" очередного значения RecId по компании DAT (все 4 миллиарда значений уже почти пройдены). Эта компания используется "штатно". Т.е. в ней формируются RecId для временных таблиц (Temporary = Yes) и для таблиц без привязки к компании (SaveDatePerCompany = No). Вот для постоянных таблиц без привязки к компании и ожидается пересечение номеров RecId.

Рецепт решения, предлагаемый в данном форуме

1. Экспорт всех таблиц без поля DataAreaId
2. Импорт с указанием опции "Предварительно стереть все данные компании"

Т.е. просто перезаливка всех данных, что приведет к генерации новых RecId.

Вызывает опасение тот факт, что большинство таблиц, которые потребуется перезалить - это служебные таблицы. Вроде SqlDictionary, UtilElements и т.п

Кто-нибудь делал подобную перезаливку? Есть какие-то "подводные камни" в этом процессе?

Ax 2.5 SP3

[kashperuk]

А SysRecIdRepair что, боитесь запускать?

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

Цитата:

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

А SysRecIdRepair что, боитесь запускать?

Не знал. Но посмотрел, что именно делает этот класс/форма и вижу, что для моих целей он не пригоден.

Для примера у нас SqlDictionary имеет

Положительные RecId в диапазоне от 1 до 2`106`710`503.
Отрицательные RecId в диапазоне от -16 до -2`147`413`227
Всего записей = 23`623

Класс SysRecIdRepair всего-лишь выполняет сдвиг всех значений RecId на некоторую фиксированную величину. Что при таком разбросе значений RecId - бессмысленно. Т.е. от "дыр" в нумерации он никак не избавит.

Ну, и кроме того, поскольку минимальное положительное значение равно 1, то сдвига вообще не будет. Разве что, взять этот класс за основу для написания собственного "перенумератора"

[glibs]

Цитата:

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

...
от "дыр" в нумерации он никак не избавит.
...

Вообще-то избавляет. Я его запускал (не теоретизирую). Правда, на 3.0.

Стандартный код имеет очень серьезные проблемы с производительностью, но править там относительно не много букв по этому поводу нужно (+ в кастомазациях не должно быть ошибок, + нужно пропатчить то, что было пропатчено к последним СП 3.0 по типам данных полей, которые ссылаются по RecId).

[kashperuk]

Цитата:

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

Не знал. Но посмотрел, что именно делает этот класс/форма и вижу, что для моих целей он не пригоден.

Для примера у нас SqlDictionary имеет

Положительные RecId в диапазоне от 1 до 2`106`710`503.
Отрицательные RecId в диапазоне от -16 до -2`147`413`227
Всего записей = 23`623

Класс SysRecIdRepair всего-лишь выполняет сдвиг всех значений RecId на некоторую фиксированную величину. Что при таком разбросе значений RecId - бессмысленно. Т.е. от "дыр" в нумерации он никак не избавит.

Ну, и кроме того, поскольку минимальное положительное значение равно 1, то сдвига вообще не будет. Разве что, взять этот класс за основу для написания собственного "перенумератора"

Он как раз наоборот, создает новую последовательность идентификаторов для каждой таблицы, поэтому, к примеру, у вас в SqlDictionary получилось бы RecId от 1 до 23623 в результате выполнения этого класса.

Поищите по форуму - с ним есть небольшие проблемы , из-за чего я и спросить "боитесь ли".

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

Да, в Ax 3.0 происходит пересоздание RecId с 1. Народ, как всегда, невнимателен, и не заметил, что речь идет об Ax 2.5, где этот класс осуществлял именно сдвиг, а не пересоздание номеров. Впрочем, разумеется, можно сделать импорт из 3.0...

Насчет "боитесь". Да. Боюсь. Иначе не спрашивал бы.

Насчет "проблем". В основном флейм идет вокруг RefRecId. Т.е. о ссылочной целостности, реализованной на кодах записи. Но, вроде бы, на системные таблицы по кодам записей никто и нигде не ссылается. Разумеется, в стандартном функционале Ax 2.5. Или я не прав?

[kashperuk]

Цитата:

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

Да, в Ax 3.0 происходит пересоздание RecId с 1. Народ, как всегда, невнимателен, и не заметил, что речь идет об Ax 2.5, где этот класс осуществлял именно сдвиг, а не пересоздание номеров. Впрочем, разумеется, можно сделать импорт из 3.0...

Насчет "боитесь". Да. Боюсь. Иначе не спрашивал бы.

Насчет "проблем". В основном флейм идет вокруг RefRecId. Т.е. о ссылочной целостности, реализованной на кодах записи. Но, вроде бы, на системные таблицы по кодам записей никто и нигде не ссылается. Разумеется, в стандартном функционале Ax 2.5. Или я не прав?

Я просто уже АХ 2.5 не видел наверное пару лет, поэтому не могу помнить детали реализации класса в этой "архаичной" системе .
Аналогично, не помню, есть ли где-то ссылки на системные таблицы. Сорри.

[somebody]

Володя,

я делал в 3.0 полное обновление RecId. В БД размером около 120 Гб исчерпались RecId, но были огромные "дыры".

Работал, сочетая методы Ax и SQL. Грубо: собрал все RecId и ссылки на RecId. Сгенерил для всех таблиц все RecId, начиная с 1, заменил все ссылки на RecId на новые.
Есть подводные камни (например, ссылки, ветвящиеся внутри Аксапты, SysDatabaseLog, кэш RecId, и др.). Не все ссылки находятся через Аксапту, кое-что через SQL-сервер.

Если ТАКОЙ метод интересует, могу снабдить подробностями.

Здесь в форуме тоже есть следы, "общался с народом", когда были проблемы со сбором ссылок.

P. S. Со служебными таблицами проблем нет, в SqlDictionary, к примеру, так же спокойно перезалил RecId'ы, а насчёт Util-таблиц - их на SQL-сервере физически нет, и ничего перезаливать не надо. Я использовал UtilIdElements именно для разборок с полями и связями.

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

Собственно, примерно это и делает класс/форма SysRecIdRepair в Ax3.0. Там достаточно простой код. Почти наглядный

Правда, в отношении компании DAT не вполне понятно, а надо ли вообще что-то делать. Там такие огромные дыры в нумерации при относительно небольшом количестве записей, что получить конфликт из-за повтора RecId представляется маловероятным. У меня подозрение, что nextValue в ней уже идет по второму кругу, а мы этого как-то не заметили

Сейчас особо времени нет, поэтому пока собираю информацию по этому вопросу...

[somebody]

Цитата:

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

Собственно, примерно это и делает класс/форма SysRecIdRepair в Ax3.0.

К сожалению, не совсем. Если бы она делала всё, что было нужно, стал бы я биться с обновлением RecId. На этой БД было много доработок, не позволяющих просто применить SysRecIdRepair, скажем, ссылок на RecId не типа RefRecId. Только не надо говорить: "Надо правильно дорабатывать", эти доработки не моих рук дело, их надо было принять как данность.
Были и другие факторы.
Скажу, что применение SysRecIdRepair было сразу отвергнуто. По причине непригодности в конкретном случае.

Почитай форум, хотя бы поищи по "SysRecIdRepair". А многое и в форуме не отражено.

Цитата:

У меня подозрение, что nextValue в ней уже идет по второму кругу, а мы этого как-то не заметили

"Везёт же некоторым..."
Когда заметите, может быть уже поздно...

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

Я с самого начала специально обратил внимание на то, что речь идет только и исключительно о компании DAT. Это весьма специфическая компания. Список таблиц, RecId которых генерится в этой компании, ну очень ограниченный. У нас порядка 150 таблиц, причем очевидно, что часть из них - мусор, который просто забыли удалить.

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

[somebody]

Цитата:

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

речь идет только и исключительно о компании DAT. Это весьма специфическая компания.

Володя, это у вас она специфическая, т. к. собственно данные множества юрлиц раскиданы по другим компаниям. Многие Аксапты работают без подобных заморочек, просто вот -- в "компании DAT". Может, некоторые читавшие эту тему и не поняли, в чём же "специфичность" компании DAT.

Цитата:

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

Не проблема по перекрестным ссылкам просмотреть использование RecId во всех этих таблицах.

Цитата:

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

ссылок на RecId не типа RefRecId

Вот на это обратил внимание? Можно по-хакерски понаделать ссылок на RecId просто типа Integer или др., а потом что-нибудь съедет, какая-нибудь доработка.
Ссылки, если помнишь, можно и через код реализовать, их нигде не будет видно...

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

Спор ради спора мне не интересен. Свою задачу я описал в самом начале темы. То, что другие используют компанию DAT как-то по другому и не удосужились прочитать мою постановку задачи, ну, это их проблемы...

При поиске по перекрестным ссылкам меня не интересуют типы данных. Меня интересует само поле (тип объекта TableField). Т.е. где и в каком месте была ссылка на поле конкретной таблицы RecId. Дальше остается посмотреть как это поле было использовано в коде. Просто прочитано, изменено или его значение было записано в какое-то другое поле.

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

В общем, технология поиска использование RecId - это уже мои проблемы...