При активной разработке расширений конфигурации в 1С:Предприятии 8.3 разработчики периодически сталкиваются с ошибкой «Не удалось заблокировать запись». Эта проблема особенно часто проявляется в типовых конфигурациях, использующих механизмы БСП (Библиотеки стандартных подсистем) для синхронизации идентификаторов объектов метаданных. Давайте разберем причины этого явления и способы борьбы с ним.
В основе проблемы лежит конфликт алгоритмов. Типовые конфигурации (например, 1С:Комплексная автоматизация 2.0) содержат процедуры, которые при обновлении конфигурации или справочника ИдентификаторыОбъектовМетаданных пытаются принудительно удалить все установленные расширения, сохранив их данные во временную структуру, чтобы после обновления восстановить их обратно.
Если в базе данных по какой-то причине (блокировки СУБД, зависшие сеансы, специфические настройки режима совместимости) транзакция удаления расширения не проходит успешно, система генерирует ошибку ВызватьИсключение. В результате процесс обновления всей конфигурации «зависает» или завершается с ошибкой.
Рассмотрим алгоритм, который вызывает ошибку. В модулях менеджера или общих модулях, отвечающих за обновление данных, часто встречается функция вида УдаленныеРасширения. Мы можем модифицировать её, чтобы сделать процесс менее «агрессивным».
Вместо того чтобы принудительно вызывать исключение при неудачной попытке удаления расширения, мы можем просто проигнорировать этот момент, что позволит системе продолжить работу.
// Пример модификации логики обработки ошибок удаления
Попытка
Расширение.Удалить;
Исключение
ИнформацияОбОшибке = ИнформацияОбОшибке;
// ТекстОшибки = ... (формирование текста ошибки)
// ВызватьИсключение ТекстОшибки; // <--- ЗАКОММЕНТИРУЙТЕ ЭТУ СТРОКУ
// Теперь исключение не прервет выполнение, и процесс пойдет дальше
КонецПопытки;
После этого изменения мы сможем успешно выполнить обновление идентификаторов объектов метаданных, что зачастую решает проблему работоспособности отчетов и прочих объектов расширения.
Если штатные процедуры БСП ведут себя некорректно, мы можем попытаться выполнить обновление «в обход», используя штатные методы платформы напрямую. Это помогает избежать принудительного удаления расширений, которое и вызывает конфликт блокировок.
Попробуем использовать метод ВыполнитьОбновлениеДанных, предоставляемый объектом Справочники.ИдентификаторыОбъектовМетаданных. Это решение выглядит более стабильным в условиях клиент-серверной архитектуры.
// Вызов принудительного обновления идентификаторов
// Истина - использовать транзакцию, Ложь - не выполнять полное перестроение если не нужно
// "Полный" - режим обновления
Справочники.ИдентификаторыОбъектовМетаданных.ВыполнитьОбновлениеДанных(Истина, Ложь, "Полный");
Разберем дополнительные шаги, которые помогут минимизировать вероятность возникновения этой ошибки:
/РежимОтладки. Это помогает платформе корректнее обрабатывать изменения в структуре метаданных расширений.srvinfo. Рассинхронизация кэша часто приводит к «фантомным» ошибкам блокировки.8.3.18, 8.3.20 и выше). Это позволяет использовать современные механизмы расширений, которые значительно стабильнее работают с БСП.Подводя итог, можно сказать, что данная проблема является следствием устаревших методов программной обработки метаданных в конфигурации. Применение одного из вышеописанных методов позволит вам снять блокировку и продолжить разработку без необходимости полного удаления расширения.