Добавить записи в регистр сведений программно. #734530

Вопрос глупый. Но, тем не менее ответа не знаю/не нашёл. Есть непериодический, независимый Регистр сведений. Одно измерение объект (ДокументСсылка) и пара ресурсов (строки) Мне нужно одной операцией добавить в этот регистр несколько записей. Вариант: НаборЗаписей = РегистрыСведений.ЗначенияСвойствОбъектов.СоздатьНаборЗаписей; НаборЗаписей.Отбор.Объект.Установить(ПолеВводаНоменклатура); не устраивает, так как нельзя установить отбор (у записей разные измерения). Вариант: не устраивает, так как пишет по одному. Почему нужно оптом: есть регламентное задание, которое должно подцепить все документы. И вариант, когда часть запишется, а часть нет не годится.

Транзакции придумали трУсы!!

Записать

Спасибо!)))

Не катит. Если выполнить запрос во время выполнения цикла, то инфа про первые строки в запрос попадает. Чего я делаю не так?

Будет же весь регистр перезаписан. А там строк может быть много.

нужно внимательно в прочитать строчку Прочитать или почитать про прочитать. или прочитать где почитать про прочитать

Менеджер записи + транзакция - не предлагать?

Наборы записей тут не очень подходят, т.к. пишут с отбором по измерениям.

"Если выполнить запрос во время выполнения цикла, то инфа про первые строки в запрос попадает." - что ты имеешь в виду?

Если нет отбора будут прочитаны все записи регистра. А потом, при Записать будут все перезаписаны. С точки зрения скорости не совсем правильно. Я пример привёл в Запускаем отладчик. Ставим точку прерывания внутри цикла. Несколько раз проходим цикл. Например в таблице 10 записей, а мы цикл проходим 3 раза. Запускаем ещё раз 1С предприятие. ваяем запрос к регистру. Эти три строчки в результате запроса видим. Должно быть: либо видим все десять. Либо не одной.

НаборЗаписей.Записать(Ложь) спасет отца русской демократии

+ без НаборЗаписей.Прочитать

Ему надо по нескольким измерениям.

Имхо, тут только управляемые блокировки спасут.

Хотя результат может отличаться от ожидаемого...

И?

А, ты предлагаешь отбор не устанавливать? Тогда прокатит, наверное.

+ Регистр сведений, независимый, отборы ставить необязательно. Создаем, заполняем(хоть каждую запись по своему измерению) и записываем.

+ Единственное что - надо тогда дубли перед записью проверять, т.к. иначе ошибка может вывалится.

Какие дубли в регистре сведений могут быть?

Что у тебя не получается в ? Зачем тебе записывать ЗаписьРегистра в Попытке?

Ну это да, тут дополнительную проверку надо Обыкновенные. Когда совпадают все измерения.

В РС есть какие-то записи. Делаешь свой набор, в котором ВНЕЗАПНО встречается запись, в которой тот же набор значений измерений, который уже есть в регистре. Пишешь через НаборЗаписей.Записать(Ложь) Имеешь ошибку.

Зачем тогда ставить ЛОЖЬ? Кстати в у него не установлен параметр Замещать = Ложь (т.е. он равен Истина)

Ему надо все записи записать одновременно. Либо сделать так, чтобы не было фантомного чтения.

+ Точней, грязного чтения.

И как параметр "Замещать" может помочь в этом деле? Только транзакция или управляемая блокировка (в зависимости от режима управления блокировкой данных).

Спасибо. Так нормально работает.

Набор записей пишется в SERIALIZABLE, если не ошибаюсь(поправь, если не так). А это как раз то, что нужно.

Если натыкается на уже имеющиеся записи с такими измерениями, то не останавливается с сообщением "Не удалось записать по причине:"? НаборЗаписей это всего лишь инструмент для удобства. По сути та же запись в транзакции нескольких ЗаписейРегистра.

>По сути та же запись в транзакции нескольких ЗаписейРегистра. Спасибо, кэп. Вопрос в уровне изоляции этой транзакции.

Хочешь сказать, что в режиме Управляемых блокировок, если я буду писать данные НаборомЗаписей и не установлю саму блокировку на записываемые данные, то я не получу возможность "грязного чтения" до окончания записи?

Утверждает, что это так. Я не проверял.

Опять же у ни слова про блокировки, может у него на регистре блокировки в автоматическом режиме.

Судя по примеру в у него таки Управляемые блокировки. Но в не утверждается "что это так", т.к. он останавливает в цикле при записи через МенеджерЗаписи. Если бы писал НаборомЗаписей, то у него и цикла никакого не было бы. В любом случае, если в конфигурации УБ, то для защиты от "грязного чтения" нужно использовать установку УБ.

Тогда пусть ставит транзакцию, считывает запросом имеющиеся данные с использованием "Для изменения" и уже потом пишет свои новые данные. Другого в 1С не придумано.

В свойствах конфы режим управления блокировкой данных - управляемый.

На регистре режим управления блокировкой данных тоже управляемый.

>В любом случае, если в конфигурации УБ, то для защиты от "грязного чтения" нужно использовать установку УБ. Ещё раз спасибо, кэп :) Я неточно выразился. Но каким-то образом у него при грязное чтение, а при записи набором - нет.

"а при записи набором - нет" — я так и не понял где такое утверждается.

в

А, хотя я туплю. У него способ проверки извращённый.

Вот и мне интересно как он это проверил. Так же интересно, что будет с "внезапно одинаковыми" записями при таком способе.

Используй принудительную блокировку в коде, иначе, при записи большого набора - всё равно получишь грязное чтение. А своим способом ты это не проверишь никак.

И еще после этого "кэп" :)

И Я еще...

Меня ввело в заблужение :)

+ заблужДение.

А надо проверять чтением из регистра, увы.