Как исправить ошибку дублирующихся ключей в уникальных индексах таблицы _USERSWORKHISTORY?

Проблема с дублирующимися ключами в таблице _USERSWORKHISTORY является специфическим сбоем, который часто встречается в файловых базах 1С:Предприятие 8.3. Особенность этой ошибки в том, что стандартные средства восстановления, такие как утилита chdbfl.exe или штатное "Тестирование и исправление" (ТиИ) в Конфигураторе, часто оказываются бессильны. Рассмотрим природу этой таблицы и разберем пошагово все доступные методы исправления ситуации.

Анализируем причину возникновения ошибки

Для начала выясним, за что отвечает таблица _USERSWORKHISTORY. Это системная таблица, в которой платформа хранит историю работы пользователей — список "Последних открытых предметов". Она содержит идентификаторы пользователей, URL-адреса объектов, дату доступа и, что самое важное, поле _URLHash (хэш по URL-адресу), изучить которое поможет структура хранения базы данных.

Проанализируем ситуацию: ошибка возникает из-за коллизий в уникальном индексе. В некоторых релизах платформы (особенно в диапазоне 8.3.8 – 8.3.15) алгоритм генерации хэша мог работать некорректно, создавая одинаковые хэши для разных URL-адресов. Поскольку индекс по хэшу уникален, появление двух одинаковых записей блокирует работу базы или вызывает её внезапное закрытие. Хорошая новость заключается в том, что данные в этой таблице не являются учетными (бухгалтерскими), и их полная очистка никак не повлияет на баланс или документы.

Способ 1: Программная очистка истории через встроенный язык

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

// Очистка истории работы всех пользователей
ИсторияРаботыПользователя.Очистить();

После выполнения этого кода попробуем снова запустить "Тестирование и исправление" с установленной галочкой "Реиндексация таблиц информационной базы". В большинстве случаев платформа сама перестроит индексы, очистка хранилища настроек пользователей также может помочь стабилизировать систему, и ошибка chdbfl исчезнет.

Способ 2: Использование SQL для исправления целостности

Если база файловая и программная очистка не помогла, рассмотрим вариант временного перехода на клиент-серверный вариант (SQL). Это позволит нам применить мощные инструменты СУБД для исправления структуры. Разберем шаги:

1. Выгрузим информационную базу в файл .dt.
2. Загрузим этот файл в пустую базу на MS SQL Server.
3. Воспользуемся системной командой DBCC CHECKTABLE, предварительно изучив инструкцию по настройке регламентных операций MS SQL SERVER под 1С.

Для начала выполним проверку без исправлений, чтобы увидеть масштаб проблемы, а также проанализируем SQL сервер глазами 1С-ника:

DBCC CHECKTABLE (_UsersWorkHistory)

Если ошибки подтверждены, выполним исправление с возможной потерей данных (в данном случае это безопасно, так как мы теряем только историю открытых окон):

DBCC CHECKTABLE (_UsersWorkHistory, repair_allow_data_loss)

После выполнения команды SQL принудительно удалит дублирующиеся записи. Затем мы сможем выгрузить базу обратно в .dt и вернуть её в файловый вариант.

Способ 3: Низкоуровневое редактирование через Tool1CD или 1CDLib

В ситуациях, когда база остается файловой и нет возможности использовать SQL, нам помогут утилиты для прямого редактирования файла .1CD. Проанализируем возможности инструментов Tool1CD или библиотеки 1CDLib. Эти инструменты позволяют работать с таблицами базы данных как с отдельными объектами.

Рассмотрим последовательность действий:

1. Обязательно создаем резервную копию файла 1Cv8.1CD.
2. Открываем базу в утилите.
3. Находим таблицу _USERSWORKHISTORY.
4. Выполняем операцию очистки (Truncate) или удаления всех записей из этой таблицы.
5. Сохраняем изменения и запускаем базу в режиме Конфигуратора для проведения реиндексации.

Важно: При использовании 1CDLib можно программно пройтись по записям и удалить только те, где дублируется _URLHash, но полная очистка таблицы технически проще и надежнее.

Способ 4: Метод выгрузки и загрузки данных через XML

Если стандартное ТиИ не справляется, а лезть в структуру файла страшно, применим метод "чистого переноса". Поскольку ошибка сидит в системной таблице, которая не является объектом метаданных (справочником или документом), она не переносится стандартной обработкой "Выгрузка и загрузка данных XML".

Выполним следующие шаги:

1. Создадим новую пустую информационную базу той же конфигурации.
2. В исходной базе запустим обработку "Выгрузка данных XML" (из состава инструментов разработчика или с ИТС) — для этого подойдёт универсальная обработка выгрузки и загрузки данных XML.
3. Выгрузим все данные (документы, справочники, константы, регистры).
4. В новой базе выполним загрузку этих данных.

Таким образом, мы получим идентичную базу, но с абсолютно чистой и исправной таблицей _USERSWORKHISTORY, так как история работы пользователей при таком переносе не сохраняется.

Способ 5: Профилактика и обновление платформы

Выясним, как предотвратить повторение проблемы. Поскольку корень зла часто кроется в механизмах индексации конкретных релизов платформы, необходимо выполнить следующие действия:

• Обновим платформу 1С:Предприятие до актуальной стабильной версии (например, ветки 8.3.22 или выше). В новых версиях механизмы кэширования и индексации истории были значительно доработаны.
• Очистим локальный кэш пользователей. Иногда ошибки "внезапного закрытия" связаны с тем, что битые индексы кэшируются локально по пути %AppData%\1C\1Cv8\.
• Проверим целостность файловой системы. Внезапные выключения компьютера могут приводить к нарушению структуры блоков файла .1CD.

Подводя итог, отметим: ошибка в _USERSWORKHISTORY неприятна тем, что мешает нормальной работе, но она не угрожает целостности вашего учета. Использование программной очистки ИсторияРаботыПользователя.Очистить() — это наиболее "цивилизованный" метод, к которому стоит прибегать в первую очередь.