Задумал я "схлопнуть" номенклатуру. Т.е. есть много записей в справочнике номенклатуры, которые идентичны по сути. Есть определенный механизм фильтрации, согласно которому можно выявить идентичные (по ряду полей) записи. Задача встала удалить все ненужные двойственные элементы, оставив только один. НО. На элементы, предполагаемые к удалению, вполне могут быть ссылки в базе. Поэтому надо сперва все ссылки заменить на тот единственный элемент, который должен остаться после "схлопывания". Функа НайтиПоСсылкам работает крайне медленно, поэтому видимо придется работать на уровне скуля. С этим сложности, т.к. под скуль практически не кодил, боюсь накосячить.
Сделайте кодес за меняпорекомендуйте плиз как выбрать все ссылки в базе из кучи таблиц

А они, эти самые ссылки, реально в базе имеются? База то хоть какая - MSSQL али что другое?
Теоретически в "идеальной" базе в метаданных смотришь констрейны ссылочной целостности и там уж видно кто ссылается на данный ключ. Но как оно в 1сной базе - понятия не имею. У нас в полностью контролируемой и разрабатываемой только нами тоже хватает "пропущенных" констрейнов - кто-то просто поленился, кто-то откровенно накосячил. Плюс есть реально сложные штуки когда констрейн сделать невозможно. Например горизонтальное разбиение таблиц - типа "сотрудники" в одной, а "клиенты" в другой, и откуда-то надо ссылаться и на тех и на других - можно, конечно завести супер-таблицу где объединить (как минимум ключи, ну можно и общие поля туда унести) данные из обеих, но зачастую разработчик ограничивается вьюхой с UNION и тут уж констрейн никак не повесить...
Писали для Оракла утилитку как раз для таких целей - унификация (устранение) дублей - она именно из all_constraints вынимала инфу кто же именно ссылается. Для MSSQL похоже эта инфа из INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS и INFORMATION_SCHEMA.KEY_COLUMN_USAGE - ну есть и в sys вьюхи сходного назначения.

преамбула
насколько я в теме, авторы 1це не замарачивались с ссылочной целостностью. видима формат их собственной базы этого не позволяет сделать, таким образом все другие базы данных, которые поддерживает 1це тож таким механизмом не озадачены. так чта вряд ли вы найдете какуюлиба инфу в базе акромя самих таблиц данных + конфигурацию с доппараметрами безопасности и работы сервера 1це
вернемся тяперича к сути вапроса. амбула
нужно иметь железные яйцачеткое представление о сути происходящего когда в обход бизнес логики напрямую лезешь в бд
не ну читать та мона кашечна и я себе иной раз себе такое позволяю, к примеру когда нуна палучить доступ к 1це а паролей нет на руках, то ты тупо грохаешь одну запись и возможно еще одну таблицу со всеми паролями и прочим
функа НайтиПоСцылкам оч примитивна и не учитывает тех реалий, по которым к примеру в какомнить документе ПриходныйКассовыйОрдер никогда не будет ссылки на справочник ПараметрыВыработкиОС, хотя канеша авторы 1це магли б и запилить такое. Ведь если искать ссылки на тот же справочник ПараметрыВыработкиОС в конфигураторе то 1це их замечательно находит менее чем за секунду
так чта задачу удаления правильнее имхо решать средствами самой 1це, ведь прогеру заранее известно по каким документам и прочим таблицам нуна искать ссылки на нужный справочник
НО. перед тем как такое вообще начинать нужно ответить на вопрос "а такое вообще допустимо и ничего не поломаеца?" к примеру, я часто встречаю конфы в которых прошлые периоды закрываются и нет никакой возможности изменять эти закрытые периоды. и это понятно с точки зрения бизнес логики, но нифига не видна с точки зрения ссылочной целестности данных
такие дела

Igor Korolyov
А они, эти самые ссылки, реально в базе имеются? База то хоть какая - MSSQL али что другое?

Имеются. MSSQL.

Foxtrot
так чта задачу удаления правильнее имхо решать средствами самой 1це, ведь прогеру заранее известно по каким документам и прочим таблицам нуна искать ссылки на нужный справочник
НО. перед тем как такое вообще начинать нужно ответить на вопрос "а такое вообще допустимо и ничего не поломаеца?" к примеру, я часто встречаю конфы в которых прошлые периоды закрываются и нет никакой возможности изменять эти закрытые периоды. и это понятно с точки зрения бизнес логики, но нифига не видна с точки зрения ссылочной целестности данных
такие дела

Так и сделал по итогам. Правда пришлось дохрена копипастить, чтоб в модуль каждого док-та и регистра воткнуть возможность записи в любом периоде без дополнительных телодвижений (конфа наполовину самопальная и просто проверка ОбменДанными.Загрузка не катит)
На тестовой базе кодес отработал на ура, будем смотреть что выйдет на продакшне

прежде чем нчать химичить в продуктиве запусти мою обработку