Цитата:
Изначально опубликовано 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
Не хотелось бы, чтоб этот топик превращался в обсуждение моего скрипта. Написал я об этом просто, чтоб знали, что если у кого то возникнет критическая ситуация с этой проблемой, то мы можем помочь её решить.
Во-первых, вряд ли мы начнем обсуждать Ваш скрипт, так как никто его кроме Вас не видел.
Рекламы в этой ветке, действительно не было. Она была в ветке, на основании которой родилась эта. Правда, с Вашим последним сообщением, намек на нее появился и здесь. Впрочем, ничего страшного в этом нет. Я вовсе не против рекламы в этом топике. Просто мне кажется достаточно странным его наличие в форуме Проекты.