😋

Ну там типа написали что не следует, а далее обоснование - мол, не ухудшает взаимодействие.
Как и в кешируемых общих модулях типа. Не зря же мы старались и сделали платформенный метод - пользуйтесь)

И это все писалось для 8.2 и с тех пор не менялось, там оно справедливо.

В 8.3 правила игры с предопределенными поменялись и это уже не действует

Очень долго работает :( при вызове на 10 000
ПредопределенноеЗначение - 0,016 с.
ОбщегоНазначенияКлиент - 1,093 с.

Ну да, еще и контекстной подсказки нету

а вот прям оно так надо делать 10к вызовов?

Ну и польза от возможности сбросить кэш только для текущего сеанса почти всегда сомнительна

Так что пожалуй продолжу использовать платформенную на клиенте)

Но с этим неявным вызовом сервера можно здорово встрять, особенно если получаешь несколько подряд и форма тяжелая

В БУХ при обходе таблицы остатков делается 89000 вызовов :( на сервере правда, но не удивлюсь что где-нить и на клиенте можно это встретить

89000 для одного и того же значения? Не страшно тогда

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

это известно, но иногда лучше завалить транзакцию, чем делать заведомо неверные операции :)

в принципе предопределенные в 8.3 работают хорошо. но есть нюансы :)

Вот, еще один момент в большей управляемости по сравнению с платформенной

Но отсутствие контекстной подсказки останавливает от применения БСПшной везде(

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

Но есть нюансы: если база подчиненного узла РИБ теряет связь с гдавным узлом вызовом метода плана обмена или пакетным режимом, то при ее запуске автоматически начинается массовое создание предопределенных которые задвоятся при первос обмене после восстановления связи с главным. Потому там еще отдельная навертка в БСП на отслеживание изменения состояния связи с главным, программное отключение создания всех предопределенных по всем метаданным и только после подтверждения администратором что это не ошибочная потеря связи начинаетсч создание предопределенных в отсоединенном подчиненном узле.

в первую очередь метод бсп надо использовать исходя из логики что база может быть неконсистента по синхрлнизации предопределенных в ИБ и в метаданных.
Либо жестко контроллировать это, в бсп в том числе в подсистеме контроль ведения учета есть раздел поиска и испоавления ошибок в предопределенных элементах.

Коллеги, подскажите плиз, настроил синхронизацию данных с использованием правил обмена (конвертация 2.1) по инструкции к подсистеме "Обмен данными" из  БСП.
Вопрос - можно ли как-то на стороне системы-получателя после загрузки сообщения отправить системе источнику подтверждение о получении сообщения? (может есть такой метод в БСП).