Цитата:
Сообщение от
mazzy
Не проблема написать. На лиспе, на си-шарп... да хоть на X++. КАК? Я ж и спрашиваю про инструмент и/или методику
Снова хочется вспомнить статью Джоэла Спольски "Где грязь, там и деньги" (цитировалась
тут). Нет у этой сложной задачи простого и ясного решения - нужно повозиться, найти все "частные случаи" - тогда, может, появится полуэвристическая методика, которая, впрочем, не факт что будет работать на 100% в других условиях. За эту "возню в грязи" клиент и платит деньги
хотя если по результатам родится некий инструмент, облегчающий решение таких задач, то будет здорово.
Цитата:
Сообщение от
sukhanchik
Поэтому - я наверное склоняюсь к правилу 20/80. Т.е. переименовать 80% объектов за 20% усилий. Просто пойти по перекрестным ссылкам. Дальше вывести - список - чего осталось. Что-то действительно руками (возможно) быстрее сделать.
Полностью поддерживаю.
Цитата:
Сообщение от
lev
так разве при заходе в аксапту, синхранизация выполняется автоматически
Часть таблиц - синхронизируется автоматически, см. \Classes\Application\syncApplTables, вызываемый в \Classes\Application\new. А еще вроде таблицы синхронизируются перед сравнением, вызываемым из формы импорта проектов.
Цитата:
Сообщение от
mazzy
Хотя... Щас писал и подумал... А ведь если у нас есть таблица соответствий, то в ней можно и дубли отследить. ДО переименования. А затем выполнить замену в текстовом файле...
Замена в текстовом файле - штука небезопасная, потому что одно имя может оказаться подстрокой другого, т.е. как минимум нужно переименовывать в режиме поиска слова целиком или использовать регулярные выражения, и все равно может оказаться, что переименование безопасно проводить лишь в определенной последовательности, а не произвольно. Это схоже с проблемами скриптов обновления данных при переходе на новый SP/версию - в руководстве по их написанию акцентируют внимание на требовании к т.н. идемотентности.
PS. Вспоминаются давнишние рассуждения касаемо дефрагментации RecId (в частности,
эти) - мне кажется, между этими задачами, если не вдаваться в технические детали, довольно много общего...