Кто и как такое делал?

Т.е. есть базу УПП на одном сервере, в ней условно 30 разных организаций. Нужна на другом сервере такая же база, но с одной организацией. Обновляемая периодически накопленными изменениями из рабочей.

РБД + план обмена "по организации"?

это вопрос или утверждение?

Как вашей фантазии удобно. Можно РБД. Но при большом объеме он будет сильно мешать параллельной работе пользователей

Можно и скрипт который раз в неделю автоматом развернет копию

(1) вопрос

(2) не будет

можно обработкой тупо за период, или анализирую ЖР

можно средсвами скулЯ репликацию настроить (теоретически)

(4) Почему? Не ужели таблица изменений теперь не одна общая на весь вид, а на неё можно наложить шибкие блокировки?

>Но при большом объеме он будет сильно мешать параллельной работе пользователей

каким образом?

база с одной организации - "витрина" для аудита, в ней активной работы не будет

>можно средсвами скулЯ репликацию настроить (теоретически)

репликация вмешивается в состав полей + придется самому отвечать за целостность на уровне каждой таблицы - это гимор

Мне в БП 2.0 пришлось отказаться от этой идеи так как работа одного пользователя по организации А блокировала работу других пользователей. И чем дольще небыло обмена, тем чаще возникал конфликт блокировок (т.е. чем больше было зарегестрированных изменений, тем хуже). Особенно актуально было в отчетный период когда каждый бухгалтер проводил документы за квартал по своим фирмам

(7) см (9)

блокировка таблицы изменений происходит в момент ВыбратьИзменения. Да, если настроена выгрузка раз в минуту, а обратной загрузки нет - будут проблемы. Если же сделать нормальное расписание, то всё будет ОК. Например сценарий обмена через вебсервис с моментальной загрузкой ответа для снятия с регистрации только что выгруженных данных.

(11) а когда событие ВыбратьИзменения наступает? при формировании выгрузки? или в момент регистрации тоже?

>если настроена выгрузка раз в минуту

пока идея была раз в неделю на выходных.

такое "расписание" будет приводить к блокировкам?

(11) не только. При загрузки подтверждения она блокируется (ичищается), при выгрузки данных она блокируется (записывается код базы куда ушли данные)

Т.е. по факту практически с момента начало обмена и до окончания.

И даже если сделать раз в минуту, ты тупо будешь мешать работать, т.е. у пользователей восстановление последовательности или групповая обработка будет вылетать из-за ощибок блокировок.

(13) Обмен ВСЕГДА блокирует данные. А вот насколько у вас за неделю у вас вырастит обмен и как он будет влиять на параллельную работу - пробуй. Вполне возможно что ты с толкнешься с этой проблемой раз в год, после полной перепроводки базы.

а если как Поп учил? три раза.
первый цикл обмена - все нужные к обмены данные перешлются.
второй цикл - все изменения подтвердятся
третий цикл - все блокировки сняты, изменений с последнего цикла нет.

>Обмен ВСЕГДА блокирует данные

в момент обмена?

в этот период в рабочей базе никого не будет

(16) как 1с узнает список объектов между щагами?

Есть конечно вариант грузит апельсины бочками, т.е. порциями например не более 50 объектов. Но в типовой это не предусмотрено, и нужно быть готовым к объект не найден, обо движение может быть загружено сейчас, а документ идёт в следующем пакете

(14) если пользоваться методом ПланыОбмена.ЗаписатьИзменения то оно будет блокировать. Если написать немного побольше кода, то время блокировки будет минимальным. Собственно, и удаление строк и простановка номера сообщения почти не занимают времени. В самом простом варианте (который, например, не используется в БСП) блокировка будет от начала выгрузки и до конца, но так уже никто не делает. При использовании БСП проблем не будет.

(20) Я описываю сейчас с тем с чем столкнулся в типовых решениях 1с. Понятно что можно написать самописку, которая будет правильно и порциями грузить обмены. Или к примеру разбить обмены на несколько - отдельно справочники, отдельно документы, и т.п.

Думаешь что ТС, возьмет и с нуля грамотно напишет обмен, или тупо возьмет типовой?

(18) ты не понял. проводить полные циклы обмена подряд. несколько раз, пока выгружаемое сообщение не будет содержать NULL.

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

(17) у каждого вида объекта есть своя таблица изменений. Т.е. одна общая таблица на все документы поступления или на весь регистр  накопления "остаткиТМЦ".
Т.е. у примеру вася пишет приход по складу "Транзит". А петя делает расход со склада "основной". Формально это два разных склада и можно реализовать паралельное проведения блокируя только остатки по определенному складу. Но так как таблица изменений общая то и Вася и Петя нарвутся на блокировку ибо попытаются писать в одну общую таблицу

(24) нет, там еще есть "регистратор"

а для ссылочных данных - ссылка. для независимых РС - комбинация измерений "основного отбора"

(23) Я пытаюсь донести мысли, не о том что проблема будет именно с обменами. Так как раз то просто сделать регламент и крутить ночью когда никого нет.
Я столкнулся с тем что когда таблица изменений, где 1с хранит данные для обмена пухнет, то возникают ошибки блокировки на ровном месте. Доходило до того что если даже я один в базе и нет обменов и перепровожу документы то возникает блокировка. Лечилось прогоном обмена

В случае ТС, если данных будет немного, он вполне возможно и не увидит этого

так что даже два документа по одному складу не заблокируют друг друга из-за таблицы изменений, даже без отбора по узлам. если же с отбором по узлам (непересекающиеся обменданными.получатели), то еще лучше.

(25) и не только, но не суть https://its.1c.ru/db/metod8dev#content:1798:hdoc

"Доходило до того что если даже я один в базе и нет обменов и перепровожу документы то возникает блокировка"
настало время офигительных историй, как одна транзакция блокирует сама себя

(28) Ну хз, у меня умудрялись блокировать работу по разным организациям.
А если в базе был ИП - это вообще вешалка, там блокировки были и без планов обмена и таблиц изменений, ибо косяк в реализации регистов накопления для ИП

(30) не транзакция, а именно изменения. Я хз как так 1с смогли сделать в типовых, но я сейчас рассуждаю как пользователь, и говорю то что вижу, а не как программист, который писал этот код в типовых

(32) ой, всё!