Доброго времени суток коллеги. Дали мне тут пару заданий на профпригодность. Прошу оценить и предложить варианты решений. Спасибо.
Задание 1. Есть Дополнительный реквизит справочника партнеры, Нужно ограничить доступ к нему. Определенным пользователям. Справочник "партнеры" с поддержки снимать нельзя, форму элемента тоже. Сделать на демо базе.
Задание 2. Надо перезаписать, просто вызвать справочник объект.записать(), для 36 000 элементов справочника, но при этом в базе работают 200 пользователей, напишите обработку, которая минимально осложнит работу пользователей во время перезаписи справочника.
Все. Всем спасибо за участие. Тестирующий забраковал оба моих решения, сказали "совсем мимо". Как нужно было я наверное уже не узнаю. Пойду учиться дальше :) Вознаграждение самым активным.
(7) Если вопросы будут интересные или у меня будут сомнения по варианту решения, то почему бы и нет. Главное чтобы коммерческая тайна не пострадала)
(4) Имелось ввиду оценить по шкале "интересно" - "не интересно". Ваша оценка в деньгах тоже интересна, посмеялся, спасибо.
Теперь по сути задач.
Задача 1. Тут уже озвучили, тоже склоняюсь к подписке на события. "ПередЗаписью" проверять изменение этого доп. реквизита нужной группой пользователей.
Задача 2. Смущает "осложнит работу пользователей". Имеется ввиду блокировка объектов, или нагрузка на сервер, или что-то еще? Блокировка скорее нам осложнит задачу а не пользователям. Если проблема в нагрузке, тогда делать порциями, хз как, еще не смотрел. Но действительно проще сделать регламентом, когда никого не будет в базе.
(20)Если пользователь начал редактировать объект (элемент справочника), а обработка его перезапишет - то это проблема для пользователя на мой взгляд - потерянное время пользователя. Поэтому попытка заблокировать объект из обработки перед перезаписью и отказ от записи, если попытка не удалась - минимизирует данную проблему (т.е. отложить запись на будущее - после разблокировки пользователем). То, что блокировка осложнит нам задачу - не противоречит тестовому заданию. В приоритете проблемы пользователя.
Надо перезаписать, просто вызвать справочник объект.записать()
Во-первых, выбрать-выгрузить ссылки в массив. Во-вторых, бегать циклом по всему массиву, получая объект, устанавливая блокировку и пытаясь записать. Если облом - идем дальше. Если ОК - удаляем из массива. Это обернуть вторым циклом до полного удовлетворения, сиречь, опустошения массива номенклатурин. Между циклами перебора массива можно воткнуть задержку на несколько секунд, чтобы когда в нем останется мало, но занятых пользователями записей, не пинать их много-много раз за секунду.
(1) по первому заданию (условимся, что это типовая на БСП) получать в расширение Формы нет смысла. Заполнение происходит не в модуле формы.
Учитывая, что в задании указано просто "ограничить доступ", намекает, что ограничение нужно не только на запись, а и на чтение. Так что подписку на событие записи так же отметаем.
Наиболее приемлемым видится путь изменения общего модуля "УправлениеСвойствамиПереопределяемый" и конкретно функции "ЗаполнитьНаборыСвойствОбъекта".
Общий переопределяемый модуль как раз намекает, что мы можем его в него вклиниться, без ущерба основной логики.
Есть Дополнительный реквизит справочника партнеры, Нужно ограничить доступ к нему. Определенным пользователям. Справочник "партнеры" с поддержки снимать нельзя, форму элемента тоже. Сделать на демо базе.
1. Нужно вставить расширение и установить проверку доступа в модуле Справочника. ПередЗаписью.
2. Я конечно знаю что вы там скажите: надо Повесить Подписку на событие "передЗаписью" итп - в итоге эти все события начнут так тормозить вместе с RLS - мало не покажется. Так что события в топку.. Настоящий программист такой халтурой не занимается..
Надо перезаписать, просто вызвать справочник объект.записать(), для 36 000 элементов справочника, но при этом в базе работают 200 пользователей, напишите обработку, которая минимально осложнит работу пользователей во время перезаписи справочника.
Если просто переалить - то лучше сделать загрузку реквизита через XML файл. ("УниверсальнаяЗагрузкаиВызрузкаОбъектов83"). Тогда
1. не будут выполняться никакие тригеры и события
2. Не будет блокировок.
3. Все зальется за 15 секунд. Ваши 200-1000 пользователей - даже об этом не поймут.
4. Правда существуют риски получить с битыми ссылками - надо много думать.
Вопрос на сообразительность:
Нужно бухгалтеру распределить сумму 10000 руб на бригаду из 7 человек поровну.
Напишите цифры от 1 до 7 (это работники) и рядом укажите сумму, которую получит каждый работник.
"Прошу оценить и предложить варианты решений."
Пожалуйста - оценка:
1 за 4 часа - 5000 р.
2 за 15 минут - 1500 р.
а вот другие варианты решения:
1 за 30 минут - 10000 р. 2 за 1 час - 1000р. или 1 за 3 часа за 6000р и 2 за 5 минут за 7500 р.
могу еще предложить кучу вариантов
1 расширение сделать, полчаса
2 если это серверная база с управляемыми формами, то можно фоновое задание смастерить. Иначе - сделать вечером, когда все уйдут. Второй вариант - полчаса, первый - ? зависит от познаний в организации этого процесса в 1с.
(10) В условии сказано
"напишите обработку, которая минимально осложнит работу пользователей во время перезаписи справочника"
На файловой базе это не реализуемо. Так как на файловой базе исключительная блокировка при записи устанавливается на таблицу в целом.
Немного странновато это файловая база на 200 пользователей
В первом задании видимо подсказка, "форму элемента тоже" - поскольку если справочник нельзя снимать с поддержки, то как следствие и форма элемента не снимется. Т.е. нужно в расширении доработать форму элемента, и, видимо, роль добавить, чтоб программно по роли прятать заданный доп.реквизит.
Второе делать в фоне, можно порциями с паузами, с предварительной попыткой заблокировать каждый объект, чтобы если пользователь начал редактировать - то не перезаписывать этот объект - а откладывать на попозже. Ссылки на отложенные для перезаписи объекты где-нибудь сохранять и пробовать перезаписать позже, когда объект освободится.
"Справочник "партнеры" с поддержки снимать нельзя"
А если максимизировать буквальный подход к тексту задания, то стоит отметить, что "Объект поставщика редактируется с сохранением поддержки" и "Объект поставщика снят с поддержки" - это разные категории, т.е. задание не запрещает вмешиваться в саму конфигурацию, можно обойтись вообще без расширения - оставить "... с сохранением поддержки" и спокойно редактировать все что нужно.
(15)Кстати, да, Sapiens_bru, можете пояснить Вашу идею с подпиской? Несмотря на подкол тестирующего, грозящий завалом теста, интересно что Вы имели в виду.
(15) Видимо я не понял что есть "ограничить доступ". Не видят и не меняют - только танцы с бубном вокруг формы. Видят но не меняют - можно подпиской
Как при втором подходе сделать ограничение написал в личку, хотя наверное зря. Речь в задаче скорее о первом
(18)Ясно. Вы просто поняли по-своему. Верно или неверно - это вопрос к тестирующему и его формулировке задачи. Если нужно ограничить только запись - то действительно, можно через подписку.
Да, вариант с подпиской уж слишком буквоедский получается. Про запрет снятия с поддержки справочника "Партнеры" написали, про остальное ни слова? Про ограничение доступа сказали, но не детализировали? Так получите же подписку - снятие с поддержки другого объекта конфигурации и ограничение доступа на запись, но не на чтение. Да Вы шутник, батенька )
достаточно в форме настройки дополнительных реквизитов и сведений настроить условия Доступности(видимости) данного реквизита. В дааном случае нам подойдет по группе доступа (в БП 3.0 профили групп ) .
(26) большинство настроек делается из-за незнания типовых механизмов. И как пример первый вопрос , большая часть решили дорабатывать конфу , и думаю, ни один не залез посмотреть что можно настроить у доп. Реквизита . Я думаю как раз на это и направлен первый вопрос
(28)А зря Вы так быстро согласились. Вот я бы сказал - большинство не проверило предложенное "решение без программирования", а начали спорить про наличие/отсутствие БСП. А по факту - предложение без программирования не подходит даже при наличии БСП. Согласны? )
А по факту - предложение без программирования не подходит даже при наличии БСП.
Что за бред вы несете?
Вместо того, чтобы воспользоваться существующим механизмом ограничения прав, изобретать собственный велосипед - кому нужны такие неадекваты?
(48)Вы хоть проверьте сначала предложенное решение задачи №1 без программирования, прежде чем определение давать, а потом ответьте себе, кто из нас с Вами неадекват ) По факту - предложенное решение без программирования не решает поставленную задачу.
(50)Я написал, что предложенное решение без программирования от vadim1011985 не решает поставленную задачу, предварительно проверив. Если Вы бросаетесь резкими словами, даже не проверяя - то Ваше категоричное "Что за бред вы несете?" - относится к Вам самому.
(50)Sashares, не увидев извинений с Вашей стороны - дам Вам совет: не являйте миру свой интеллект в столь резких выражениях в отношении собеседников, как "бред, неадекват". Если понимания Вам не хватает - следите за общением толковых людей, и обратите внимание на сообщение vadim1011985 №54 в этой ветке.(54)
(27) ТС не указал по какой конфигурации вопросы, вообще не факт, что там есть БСП, так то.
Но конечно, если речь про доп. реквизиты, логично предположить, что БСП там таки есть.
(31) Ну не совсем. Даже в НК написан по принципу "Если явно не указано , то разрешено/запрещено" Соответственно в задаче не сказано что это ОФ - значит можно считать что это УФ , не сказано конфигурация типовая или самописная - считаем что типовая , не сказано используется БСП или нет - считаем используется. - отсюда такой вариант решения
P.S точнее в вопросе есть приписка сделать это в демо-базе . ТС не указал что это за демо база . А без этого трудно сказать что есть , а чего нет. Или может сам ТС может выбрать демо-базу по своему усмотрению
Надо признать , что в словах uno-c есть изрядная доля правды , так как действительно в предложенном мной варианте мы привязываемся к реквизиту самого справочника партнеры. а не к справочнику пользователи или конкретному пользователю С одной стороны мы можем создать отдельную группу (группы) доступа и назначить их для партнеров что правильно работало ограничение , но с другой стороны для надежного закрытия нужно прогить
(52)Ограничение должно работать не для партнера в целом, а для отдельного доп.реквизита. Вам не поможет создание отдельной группы доступа для того, чтобы у одних пользователей доп.реквизит был доступен, а для других - недоступен. Т.е. типовыми средствами через доступность доп.реквизита вообще не решить поставленную задачу.
(44)Даже ограничение доступности доп.реквизита в зависимости от значения реквизита "Группа доступа" не решит поставленную задачу. Т.е. предложение без программирования неверно, независимо от наличия БСП.
(25)Группа доступа - это реквизит справочника Партнеры. А ограничивать нужно в зависимости от пользователя, а не от значения какого-то реквизита конкретного Партнера. Ваше решение - это не решение обозначенной задачи. Т.е. если у элемента - Партнера будет неподходящая группа доступа - доп.реквизит не будет доступен никому.
Ну так я о том и сказал выше, что если не указано дополнительно, то изначально нужно рассматривать некий общий способ решения. Если появятся уточнения, напрямую влияющие на решение, то и решение может измениться в сторону частного.
1. Предполагаю, что делается это ограничение в общем модуле СобытияФорм или СобытияФормПереопределямый или как-то так. Наверное, от УТ зависит.
Скорее всего сначала идёт инициализация переменных формы для кеширования и работы с доп реквизитами, а потом уже переопределение формы.
Полагаю, чтобы ограничить доступ к конкретному доп реквизиту нужно просто удалить его из кеша/реквизита формы. Но это лишь размышления, надо проверять.
2. Сомневаюсь, что перезапись 36к элементов осложнит работу пользователей. Может речь и правда про попытку заблокировать объект перед записью... чтобы не было предупреждения об изменении версии объектов или какую там ошибку платформа выдаёт.... типа "данные были изменены.." или что-то похожее. А, ещё, может быть, косвенно речь про отключение проверок и действий перед записью (Объект.ОбменДанными.Загрузка = Истина), кто знает, сколько там всего...
Решил первую задачку. Можно конечно по разному трактовать "ограничить доступ". Я остановился на варианте, что программа выдает ошибку при его изменении.
Сделал подписку на событие "ПередЗаписью". В обработчике такая процедура:
Процедура ПроверитьДосутДопРеквизит(Источник, Отказ) экспорт
//Наименование доп реквизита у справочника партнеры "ИзбранныйРеквизит"
//Разрешено менять реквизит группе пользователей "ИзбранныеПользователи"
ЗапретитьИзменятьДопРеквизит = Истина;
//смотрим какое значение пытаются сохранить
ЗначениеРеквизитаНовое = "";
Для каждого стр из Источник.ДополнительныеРеквизиты цикл
если стр.Свойство.Заголовок = "ИзбранныйРеквизит" тогда
ЗначениеРеквизитаНовое = стр.Значение;
конецесли
конеццикла;
//смотрим какое значение было до изменений
ЗначениеРеквизитаСтарое = "";
Для каждого стр из Источник.Ссылка.ДополнительныеРеквизиты цикл
если стр.Свойство.Заголовок = "ИзбранныйРеквизит" тогда
ЗначениеРеквизитаСтарое = стр.Значение;
конецесли
конеццикла;
если ЗначениеРеквизитаНовое <> ЗначениеРеквизитаСтарое тогда
// проверяем что пользователь входит в нужную группу
ТекПользователь = ПараметрыСеанса.ТекущийПользователь;
ЗапросПраваПользователя = новый Запрос;
ЗапросПраваПользователя.УстановитьПараметр("НаименованиеГруппыДоступа","ИзбранныеПользователи");
ЗапросПраваПользователя.УстановитьПараметр("Пользователь",ТекПользователь);
ЗапросПраваПользователя.Текст = "ВЫБРАТЬ
| ГруппыДоступаПользователи.Пользователь
|ИЗ
| Справочник.ГруппыДоступа.Пользователи КАК ГруппыДоступаПользователи
|ГДЕ
| ГруппыДоступаПользователи.Ссылка.Наименование = &НаименованиеГруппыДоступа
| И ГруппыДоступаПользователи.Пользователь = &Пользователь";
ВыборкаПользователей = ЗапросПраваПользователя.Выполнить().Выбрать();
Если ВыборкаПользователей.Следующий() тогда
ЗапретитьИзменятьДопРеквизит = Ложь;
иначе
ОбщегоНазначенияКлиентСервер.СообщитьПользователю("Вы не можете изменить реквизит 'ИзбранныйРеквизит', обратитесь к Администратору.");
КонецЕсли;
КонецЕсли;
Отказ = ЗапретитьИзменятьДопРеквизит;
КонецПроцедуры
(57)Таким образом, Вы включили возможность изменения конфигурации? Если так - прошу сообщить, как тестирующий отреагировал на такое Ваше решение. И ограничить доступ - не самая общепринятая трактовка: если набрать в Яндексе "ограничить доступ" - то вся первая страница на тему "совсем закрыть, чтоб не видели".
(59) Согласен, ограничить доступ - либо скрыть видимость либо убрать возможность изменения (как минимум интерактивного и как максимум + любого). Полагаю нужно как минимум удалить элемент формы этого реквизита.
А причем тут возможность внесения? Ведь указано, что партнеры на полной поддержке, а не конфа)
Ведь указано, что партнеры на полной поддержке, а не конфа)
Да-да, я уже оценил этот прикол, вопрос как к нему отнесется тестирующий, а они ведь всякие бывают.И партнеры тоже по тексту задания - не на полной поддержке, а "с поддержки снимать нельзя". В конфигураторе разные опции "Объект поставщика редактируется с сохранением поддержки" и "Объект поставщика снят с поддержки", т.е. под текст задания если читать буквально - подойдет и редактирование модулей самого справочника, ведь поддержка сохранена ).
(63)Разумеется, это была шутка. Но доля правды в ней то, что корректней писать не "с поддержки снимать нельзя", правильнее будет "включать возможность редактирования нельзя". Я привык писать ТЗ предельно четко, таких вольностей, как в топике обычно себе не позволяю, разве что проверить, что тебя понимают с полуслова. И в данном задании мне кажется, что раз нельзя снимать с поддержки справочник, то и всю конфу нужно оставить в покое.
Я вот так первую решил:
МодификацияКонфигурацииПереопределяемый.ПриСозданииФормы:
//++
Если Форма.ИмяФормы = "Справочник.Партнеры.Форма.ФормаЭлемента" Тогда
УправлениеСвойствами.ЗаполнитьДополнительныеРеквизитыВФорме(Форма); // по умолчанию заполнение отложенное, вызовем принудительно
Если Не Пользователи.ЭтоПолноправныйПользователь() Тогда // тут какое-либо условие
ЗапрещенноеСвойство = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоРеквизиту("Имя", "_ТестовыйРеквизит");
НайденныеСтроки = Форма.Свойства_ОписаниеДополнительныхРеквизитов.НайтиСтроки(Новый Структура("Свойство", ЗапрещенноеСвойство));
Если НайденныеСтроки.Количество() Тогда
СтрокаОписания = НайденныеСтроки.Получить(0);
Форма.Элементы.Удалить(Форма.Элементы[СтрокаОписания.ИмяРеквизитаЗначение]);
Форма.Свойства_ОписаниеДополнительныхРеквизитов.Удалить(СтрокаОписания);
КонецЕсли;
КонецЕсли;
КонецЕсли;
//--
Решил вторую задачу. Посчитал, что наиболее феншуйно сделать ее в фоне. Автор задачи намекал на ресурсоемкость. Дополнительно обработку можно запустить по расписанию. Откладывание заблокированных элементов на последующую перезапись решил не делать, думаю не в этом была задача. Перебор сделал максимально просто:
ВыборкаЭлементовСправочника = Справочники.Номенклатура.ВыбратьИерархически();
пока ВыборкаЭлементовСправочника.Следующий() цикл
если не ВыборкаЭлементовСправочника.ЭтоГруппа тогда
ОбСпр = ВыборкаЭлементовСправочника.ПолучитьОбъект();
//ОбСпр.Описание = "тест";
попытка
ОбСпр.Записать();
исключение
//отложить элементы которые не удалось записать, например во внешний файл
конецпопытки;
конецесли;
конеццикла;
(67)И как это решение "минимально осложнит работу пользователей" ? Пользователь начал редактировать партнера, десяток минут пыхтел-старался, а ему при записи - на тебе - "элемент изменен другим пользователем, запись невозможна".
В условии этой задачи нет указания справочника. Для примера взял "номенклатуру".
(71) Может отличается среда выполнения. У себя попробовал и с открытым элементом, и с изменным - ошибок не было. Пользовательские изменения просто перезаписывали изменения обработки.
(73) "Запросы insert в цикле." как сделали бы вы? Можно еще было запросом, это вы имеете ввиду?
"Запросы insert в цикле." как сделали бы вы? Можно еще было запросом, это вы имеете ввиду?
Получить ссылки на элементы и разбить по нескольким массивам. Выполнять в разных потоках. Получение объектов и запись выполнять порциями в единой транзакции.
Количество потоков и порции для транзакции подбирать исходя из возможностей сервера и его нагруженности.
При ошибках транзакции переносить ссылки незаписанных элементов в отдельный массив. По окончанию основной работы пытаться повторно записать уже с другими порциями.
Ссылки на элементы получать конечно же запросом без иерархии и групп. Зачем нам нужна иерархия и группы?
Получить ссылки на элементы и разбить по нескольким массивам. Выполнять в разных потоках. Получение объектов и запись выполнять порциями в единой транзакции.
Количество потоков и порции для транзакции подбирать исходя из возможностей сервера и его нагруженности.
Так это же наоборот повысит нагрузку, а в задании указано сделать наоборот)
Правильно предлагали блокировку накладывать перед записью - вот основной посыл решения.
(79) не надо путать наименьшую нагрузку своего кода и "напишите обработку, которая минимально осложнит работу пользователей во время перезаписи справочника"
Если мы будем делать запись в едином потоке и получать с последующей записью без порций и последовательно дергать сервер для записи, тогда только усложним работу пользователям.
И что имеется ввиду под фразой: "Правильно предлагали блокировку накладывать перед записью - вот основной посыл решения."? Это как?
(81) про пик нагрузки днем это уже отсебятина. Вопрос: Загрузить сервер на 10 минут или на 1 минуту это будет являться "минимально осложнит работу пользователей"?
Приведенная ссылка совсем из другой области. Нам не надо ничего изменять в получаемом объекте, а просто записать.
Т.е. код:
(82) Дело не во времени, в описании могли указать 1000 пользователей и 1кк элементов. Дело в подходе реализации таких задач. И многопоточность тут точно только навредит, к гадалке не ходи.
нужно, ибо в первом случае обычно через попытку установки блокировки делается, дабы обработать таку. ситуацию, в нашем случае, допустим, отложить обработку проблемного элемента на потом.
(83) блокировку в примерах по ссылке делают для того, чтобы убедиться, что можем изменить и записать. Иначе смысла что-то изменять нет. Все.
При записи автоматически уже накладывается блокировка. И смысла дополнительно его накладывать нет совсем.
(84) вы читали статью.
ЗЫ: в бсп сейчас, кстати, накладывается транзакционная блокировка при обработке данных.
Модуль менеджера объекта ОбработатьДанныеДляПереходаНаНовуюВерсию()
Пока Выборка.Следующий() Цикл
УстановленаБлокировка = Ложь;
НачатьТранзакцию();
Попытка
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить(ПолноеИмяОбъекта);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.УстановитьЗначение("Ссылка", Выборка.Ссылка);
Блокировка.Заблокировать();
ДокументОбъект = Выборка.Ссылка.ПолучитьОбъект();
Если ДокументОбъект = Неопределено Тогда
ОтменитьТранзакцию();
Продолжить;
КонецЕсли;
...
(86) Не понимаю, что вы хотите сказать. В статье показано, как работать с объектными пессимистическими блокировками, чтобы избежать ситуации, когда данные были кем-то изменены. Из описания указано, что идёт активная работа с БД.
А вы хотите принудительно изменить объект, поменять версию, и все изменения, что делал пользователь отменить.
Может отличается среда выполнения. У себя попробовал и с открытым элементом, и с изменным - ошибок не было. Пользовательские изменения просто перезаписывали изменения обработки.
Что-то не так пробовали.
Открыли элемент справочника в форме и изменили его (можно даже не изменять). Версия элемента "АААА"(псевдо версия)
После этого в фоне произошла перезапись этого же элемента справочника. Версия стала "АВАА"
После этого на форме попытаться записать. Версия не совпадает. Будет выдана ошибка.
Но это не основное в задании. Эту ошибку практически не решить внешней обработкой. При открытии элемента в форме блокировка не накладывается. В УФ после открытия формы элемента даже полученный объект удаляется. Т.е. ничего не связывает форму элемента и запись в SQL.
Эту ошибку практически не решить внешней обработкой.
Это как раз частично и решается попыткой блокировки из кода решения задачи. Если пользователь начал редактировать - автоматом установилась пессимистическая блокировка. Эта блокировка не запретит обработке из другого сеанса записать данный элемент, но обломает попытку заблокировать объект из другого сеанса. При неудачной попытке заблокировать - нужно отказаться от записи (несмотря на то, что запись не запрещена, если попытаться записать без СправочникОбъект.Заблокировать() - то все нормально пройдет), отложить этот элемент и вернуться позже.
(89) частично соглашусь. В таком ключе не рассматривал.
Но это если пользователь уже начал редактировать.
Если форму еще не изменяли или изменили после перезаписи в другом сеансе, то ошибка никуда не денется.
(90)Если форму элемента открыли, но еще не меняли, затем в другом сеансе обработка перезаписала объект, то в дальнейшем при начале редактирования в открытой форме у меня выдается "Данные были изменены или удалены другим пользователем" - еще одно осложнение пользователя снято.
Таким образом, если изменили после перезаписи в другом сеансе - то значит пришлось перечитать сохраненное обработкой, и вообще потерь времени пользователя не будет - т.е. все обозначенные Вами в (90) проблемы пользователя сняты путем попытки заблокировать объект из обработки и отказа от записи, если попытка не увенчалась успехом.
Может отличается среда выполнения. У себя попробовал и с открытым элементом, и с изменным - ошибок не было. Пользовательские изменения просто перезаписывали изменения обработки.
Не может быть. Версии разные, платформа должна была "ругнуться". Даже на файловой такое же поведение.
Открыл карточку, начал редактировать. Далее обновил в другом сеансе (не обязательно фоново). Попытаешься записать в первом сеансе - ошибка "данные были изменены.."
(69)Не знаю как на самых последних платформах - но до них пессимистическая блокировка не запрещала запись объекта. Т.е. если пользователь начал редактировать партнера, но еще не записал, и в это время из другого сеанса вызвать код записать() данного партнера - то код успешно сработает, а вот пользователю потом придет облом при попытке записи - все изменения пользователю придется переписывать, предварительно обновив данные партнера.
(72) там в (69): "ВыборкаЭлементовСправочника = Справочники.Номенклатура.ВыбратьИерархически();"
По-этому с партнером будет все в порядке :)
Конечно это не отменяет основной критики.
Но проблема в том коде даже не в этом, а в попытке записать большой объем данным единым потоком, с циклическими единичными транзакциями. Запросы insert в цикле.
Все. Всем спасибо за участие. Тестирующий забраковал оба моих решения, сказали "совсем мимо". Как нужно было я наверное уже не узнаю. Пойду учиться дальше :) Вознаграждение самым активным.