Как выполнять дефрагментирование RecID

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Анализ алгоритма "Проверки кодов записей" показал, что при любых эксплуатационных условиях он не исправляет никаких ОЛЦД,

Да он, собственно, для этого и не предназначен.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
а может добавлять свои.

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

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Алгоритм достаточно простой, просто посмотрите, как себя он себя поведет, если есть дубликаты recid в разных таблицах, как будет работать с виртуальными компаниями, если есть ссылки, которые ссылаются на несуществуюшие строки, и наконец типы, которые не наследуются от recid.

По пунктам:
(1) Виртуальные компании
Если в таблицах, которые разделяются между компаниями, входящими в виртуальную, есть ссылки на RecId между собой, ситуация будет обработана корректно. Если есть ссылки из разделяемых таблиц на не разделяемые или наоборот - это уже ошибка целостности данных. Таким образом, процедура проверки кодов записей новых ошибок в этом случае не добавляет, а лишь повторяет старые.
(2) Ссылки на несуществующие строки
Проверка кодов записей сообщит о таких строках в infolog. Исправлены они не будут.
(3) Типы, которые не наследуются от RecId
Поля с такими типами, разумеется, не будут обработаны. Однако это, по сути, ошибка программистов. Кроме того, таблиц с такими полями, я что-то немного нашел (1 в 3.0 и 3 в 2.5).

Таким образом, проверка кодов записей практически (кроме (3)) во всех указанных случаях не добавляет ошибок целостности данных. Правда, не исправляет имеющихся, но этого никто и не обещал. Для таких процедур есть стандартная функциональность "Проверка целостности данных"

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Я просто дал совет. Хотите-разберитесь, хотите-проигнорируйте.

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

Цитата:

Изначально опубликовано Yaroslav Batozskiy
При relation ссылка не пересчитается при exp-imp и прочих оп.

А она, знаете ли, и не должна пересчитываться. Это ID проводки. Он импортируется вместе с проводкой из файла импорта. Это не RecId, который становится новым при импорте для каждой записи.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Да Бог с ней, с трансляцией, таких полей в системе туча, и много их в тех модулях, которые используются редко.
Максим, искать и приводить здесь не буду

Да, аргументация у Вас... Просто виновна, а почему не скажу... Далеко Вы так уйти можете.

В общем, я таких мест нашел не много (см. выше: всего одно).

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Максим, если речь идет о моем скрипте

Нет, речь о стандартной процедуре дефрагментации. Вашего скрипта я не видел.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Не хотелось бы, чтоб этот топик превращался в обсуждение моего скрипта. Написал я об этом просто, чтоб знали, что если у кого то возникнет критическая ситуация с этой проблемой, то мы можем помочь её решить.

Во-первых, вряд ли мы начнем обсуждать Ваш скрипт, так как никто его кроме Вас не видел.
Рекламы в этой ветке, действительно не было. Она была в ветке, на основании которой родилась эта. Правда, с Вашим последним сообщением, намек на нее появился и здесь. Впрочем, ничего страшного в этом нет. Я вовсе не против рекламы в этом топике. Просто мне кажется достаточно странным его наличие в форуме Проекты.