Удавление дубликатов

[Yaroslav Batozskiy]

Провел небольшую исследовательскую работу, результатом которой стало два скрипта http://www.crm.columbus.ru/ep/yarb/C...eHierarchy.xpo и http://www.crm.columbus.ru/ep/yarb/C...ldWithType.xpo

Первый можно использовать просто для исследований—он создает в темповой папке CSV-файл, в который пишет по три значения для каждого поля каждой таблицы—таблица, поле, расширенный тип поля с иерархией до корня. Например так: CustTable,AccountNum,CustAccount<-CustVendAC<-ExternalAccount<-String, что означает: в таблице CustTable есть поле AccountNum с типом CustAccount, который наследуется от CustVendAc, который наследуется от ExternalAccount, который является строкой.

Поскольку файл CSV, для просмотра лучше импортировать его в Excel как CSV, с разделителем «запятая»

Второй файл сделан из первого и решает конкретную задачу—при переименовании первичного ключа находит, какие еще поля в каких таблицах имеют такой же EDT, или унаследованный от него. Он содержит один параметр—в строке 4—тип, который мы ищем. Отличия от стандартного механизма перекрестных ссылок—скрипт находит и те поля, типы которых _унаследованы_ от искомого.

Если нужно сделать одно переименование/объединение—то это можно сделать и вручную через Query Analyzer тем оператором, который я приводил выше для каждого поля. Если много—можно в скрипт после строки 49 (команда aio.write()) добавить вызов этого оператора SQL с проставленными переметрами (таблица, поле, оба значения—старое и новое), пример см. в \Classes\SysRecidRepair\ExecuteUpdate. Тогда в скрипт нужно добавить еще два параметра «что присоединить» и «к чему присоединить»--и он становится почти универсальным.

Скрипт этот можно использовать и для объединения, и для переименования
Добавлю, что скрипт этот работает тоже через иерархию типов. Если таблицы связаны по Relation—он работать не будет. Если его использовать для переименований—то он будет работать так же, как и штатная функция, только на порядок быстрее при большом объеме данных. И если у вас есть поля, в который неправильно проставлен EDT, то оба эти скрипта поле не обновят.

Я довольно часто сталкивался со случаями неправильно расставленных EDT. Например при дефрагментировании RecId я обнаружил, что есть поля со ссылками по Recid, тип которых не наследуется от RecId (в результате чего при экспорте-импорте эти ссылки пересчитаны не будут, т.е. данные в таблице будут повреждены). Пример—поле RTSLSessionTransId в таблице LedgerTrans (номер сессии трансляции, которая породила проводку). Если скрипт используется для переименования только одного поля—то можно в скрипт добавить оператор для обработки такого нестандартного поля, если для многих полей—то это придется сделать врукопашную.

Важно: все обновления должны проводиться в одной транзакции!

Если нужно--можно доработать скрипт, для системного решения проблемы объединения\переименования счетов при любом количестве записей. Используя SQL для обновлений получаем скорость работы как минимум на порядок больше, чем штатными средствами.