При работе с крупными информационными базами, такими как 1С:Управление производственным предприятием (УПП) ред. 1.3, специалисты часто сталкиваются с ситуацией, когда после процедуры свертки данных или при попытке "подлить" конфигурацию из идентичной базы возникает критическая ошибка. Процесс обновления прерывается сообщением СУБД о невозможности вставки повторяющейся ключевой строки в объект, связанный с планом счетов.
В этой статье мы подробно разберем, почему возникает ошибка в таблицах _Acc23_ExtDim, как проанализировать дубли на уровне SQL и как корректно сопоставить предопределенные элементы, если система выдает ошибку о несовместимости ссылок.
Рассмотрим ситуацию, описанную в проблеме. Ошибка указывает на таблицу dbo._Acc23_ExtDim1549NG. В структуре базы данных 1С таблицы с префиксом _Acc относятся к планам счетов. Суффикс ExtDim означает, что это таблица табличной части, где хранятся настройки видов субконто для каждого счета.
Индекс _ByLineNo обеспечивает уникальность комбинации полей "Счет" + "Номер строки". Когда при обновлении конфигурации система пытается пересчитать или перезаписать эти данные, она натыкается на записи, которые нарушают это правило. Это может произойти, если:
Прежде чем приступать к радикальным мерам вроде очистки таблиц, проанализируем, какие именно данные мешают обновлению. Мы можем использовать SQL Server Management Studio (SSMS) для поиска дублей. Выясним, для каких счетов нарушена нумерация строк субконто.
Для этого выполним следующий запрос (замените имя таблицы на актуальное из вашей ошибки):
SELECT _AccountIDRRef, _LineNo, COUNT(*)
FROM _Acc23_ExtDim1549
GROUP BY _AccountIDRRef, _LineNo
HAVING COUNT(*) > 1
Если запрос вернул строки, значит, в базе действительно есть записи с одинаковым номером строки для одного и того же счета. Рассмотрим подробнее: поле _AccountIDRRef содержит уникальный идентификатор счета. Чтобы понять, что это за счет в интерфейсе 1С, мы можем соединить эту таблицу с основной таблицей плана счетов _Acc23.
Важно: Вместо полного удаления данных через TRUNCATE, как сделал автор темы, лучше точечно удалить дублирующую запись или программно изменить её номер строки (поле _LineNo) через прямой SQL-запрос, если вы уверены в своих действиях и имеете бэкап.
После устранения ошибки SQL может возникнуть следующая проблема: Несовместимая ссылка предопределенного элемента. Например, для справочника СпособыОпределенияПоставщиков. Это происходит, когда в основной базе и в базе-источнике конфигурации (cf-файла) один и тот же предопределенный элемент имеет разные внутренние идентификаторы (GUID).
Разберем, как восстановить целостность данных без удаления справочников:
{93f50025-9033-c7b8-11e5-fb31ed99e4d9}) — это то, что прописано в метаданных.УстановитьСсылкуНового(), но для уже существующих предопределенных данных лучше использовать метод УстановитьДанныеПредопределенного() или воспользоваться обработкой "Установка ссылок предопределенных данных" из состава БСП._IDRRef в таблице справочника, чтобы оно соответствовало идентификатору из конфигурации. Но помните, что после этого придется обновить все ссылки на этот элемент во всех документах и регистрах, иначе они "повиснут".Рассмотрим ситуацию, когда пользователь выполнил команду TRUNCATE TABLE для таблиц субконто. Это действительно позволяет обновлению завершиться, так как таблицы становятся пустыми и уникальный индекс более не нарушается. Однако, проанализируем последствия:
Потеря аналитики: Таблицы _ExtDim хранят связь счета с видами субконто (например, Счет 60 — Номенклатура, Контрагенты, Договоры). Очистив эти таблицы, вы получите "голый" план счетов. В режиме "1С:Предприятие" счета будут выглядеть так, будто у них не задано ни одно субконто. Все отчеты (Оборотно-сальдовая ведомость и др.) перестанут показывать аналитику, хотя сами проводки в регистре бухгалтерии могут содержать значения субконто. Провести новые документы по таким счетам будет невозможно без восстановления настроек.
Поэтому, если вы использовали TRUNCATE, вам необходимо сразу после обновления выполнить Тестирование и исправление (ТиИ) с включенной опцией "Реорганизация данных", либо восстановить настройки субконто программно, сопоставив их с типовой конфигурацией.
После того как технические препятствия на уровне СУБД устранены, выполним обязательные регламентные действия:
srvinfo (кроме файлов логов и настроек кластера), затем запустите службу снова. Это исключит влияние старых описаний метаданных.UPDATE STATISTICS для всей базы данных. Это поможет оптимизатору запросов SQL Server корректно работать с обновленными таблицами.Режим совместимости. Для УПП 1.3 на платформе 8.3.12 это критически важно для корректной работы механизмов предопределенных данных.Подводя итог, можно сказать: проблема с уникальностью индексов при обновлении — это всегда следствие "мусора" в данных. Наиболее правильный путь решения — найти конкретный дубль в SQL, понять причину его появления (например, ручное добавление субконто, которое стало предопределенным) и устранить его точечно, сохранив общую структуру аналитического учета.