В практике разработки на платформе 1С:Предприятие часто возникает ситуация, когда регистр сведений имеет несколько измерений, но логически одно из них (например, уникальный идентификатор или внешний код) однозначно определяет запись. При попытке удалить такую запись программисты часто сталкиваются с тем, что объект МенеджерЗаписи ведет себя не так, как ожидалось. Давайте подробно разберем, почему это происходит, в чем разница между ключевыми объектами для работы с регистрами и как выбрать наиболее эффективный метод удаления данных.
Рассмотрим стандартную ситуацию: у нас есть регистр сведений с пятью измерениями. Одно из измерений — ИД — является уникальным. Разработчик пытается использовать РегистрСведенийМенеджерЗаписи, устанавливает только это одно измерение и вызывает метод Прочитать(). В результате получается пустая запись, хотя данные в базе точно есть. В то же время, если использовать РегистрСведенийНаборЗаписей с отбором по тому же самому ИД, запись успешно находится и удаляется.
Проанализируем причину такого поведения. Менеджер записи в системе 1С является «проекцией» конкретной строки таблицы. С точки зрения архитектуры базы данных, уникальность записи в регистре сведений обеспечивается совокупностью всех его измерений. Платформа 1С при вызове метода Прочитать() у менеджера записи формирует SQL-запрос, в секции WHERE которого перечисляются абсолютно все измерения регистра. Если вы не указали хотя бы одно измерение, поиск по «полному ключу» не может быть выполнен корректно, и система возвращает результат, свидетельствующий об отсутствии записи.
Для лучшего понимания физического смысла измерений рассмотрим пример с двумерной таблицей (аналог листа Excel). Представьте, что измерения — это координаты ячейки: номер строки и номер столбца. Если вы хотите прочитать значение конкретной ячейки (аналог Менеджера записи), вам обязательно нужно указать обе координаты. Нельзя сказать «дай мне ячейку из 5-й строки» и ожидать, что система сама догадается, какой это столбец, даже если в этой строке заполнена всего одна ячейка.
В то же время Набор записей работает как фильтр или выборка. Вы можете установить фильтр только по строке (одному измерению) и получить все ячейки, которые в эту строку входят. Даже если там всего одна запись, Набор записей ее увидит, потому что его логика — это поиск по диапазону или частичному совпадению ключа.
Если в вашей архитектуре известно только одно измерение, использование объекта НаборЗаписей — это самый прямой и производительный путь. Вам не нужно делать предварительных запросов к базе данных, чтобы узнать значения остальных четырех измерений. Вы просто создаете набор, устанавливаете отбор и записываете пустой результат.
Рассмотрим по шагам, как это реализовать в коде:
// Создаем объект Набор записей
НаборЗаписей = РегистрыСведений.Лог.СоздатьНаборЗаписей();
// Устанавливаем отбор по известному нам уникальному полю
НаборЗаписей.Отбор.ИД.Установить("2784678867236862862862");
// Выполняем запись пустого набора.
// Параметр Истина означает, что данные в базе будут замещены данными набора.
// Поскольку в наборе записей нет, строка с указанным ИД будет удалена.
НаборЗаписей.Записать(Истина);
Важно помнить: метод Записать(Истина) удалит все записи, которые попадают под установленный отбор. Если ваше поле ИД действительно уникально, удалится ровно одна запись. Это эффективнее работы с менеджером, так как исключается лишняя операция чтения перед удалением.
Если же вы принципиально хотите использовать МенеджерЗаписи, вам придется сначала программно «достроить» полный ключ записи. Это требует большего количества ресурсов, так как подразумевает выполнение дополнительного запроса.
Проанализируем последовательность действий при таком подходе:
ИД.СоздатьМенеджерЗаписи().Удалить().Этот метод считается избыточным для простых операций удаления, но он может быть полезен, если перед удалением вам необходимо выполнить сложную логику проверки данных в самой записи.
При использовании удаления через Набор записей критически важно обратить внимание на структуру самого регистра. Скорость поиска записи для удаления напрямую зависит от того, как настроены измерения:
ИД стоит первым в списке измерений, система найдет запись мгновенно.ИД не является первым, проверьте, установлено ли для него свойство Индексировать. Без индекса системе придется сканировать всю таблицу регистра, что при миллионах записей приведет к серьезным блокировкам и тормозам.Выясним причину, по которой опытные разработчики предпочитают Набор записей. При работе с Менеджером записи платформа пытается наложить блокировку по полному первичному ключу. Если же используется Набор записей с отбором, 1С накладывает блокировку на диапазон значений. В случае, когда мы фильтруем по уникальному идентификатору, этот диапазон сужается до одной записи. Однако использование набора избавляет нас от необходимости сначала «читать» запись, что уменьшает время удержания транзакции и снижает риск возникновения конфликтов блокировок в многопользовательской среде.
Существует еще один вспомогательный объект — КлючЗаписиРегистраСведений. Он часто используется в формах списков. Если у вас уже есть ссылка на ключ (например, вы получили его из строки динамического списка), вы можете инициализировать менеджер записи напрямую:
// Предположим, КлючОбъекта получен из параметров или формы
Менеджер = РегистрыСведений.Лог.СоздатьМенеджерЗаписи();
Менеджер.Заполнить(КлючОбъекта);
Менеджер.Удалить();
Этот вариант удобен тем, что метод Заполнить() автоматически подставит все необходимые измерения из ключа, избавляя вас от ручного заполнения каждого поля.
Подводя итог, можно сказать: поведение Менеджера записи, требующее указания всех измерений — это не ошибка, а фундаментальная особенность архитектуры 1С, обеспечивающая целостность данных. Для удаления записи по частичному набору данных (одному или двум измерениям из многих) всегда используйте НаборЗаписей. Это наиболее производительный, надежный и лаконичный способ, который является стандартом в среде профессиональной разработки.