Есть одинаковые по структуре базы 1С, лежащие на одном сервере.
На них нужно поддерживать "почти" полную синхронизацию данных:
синхронизироваться должны полностью все данные справочников, документов регистров за исключением некоторых текстовых полей в некоторых справочниках.
Понятно, что такую синхронизацию можно поддерживать с помощью РБД или с помощью COM-соединений.
Но вот допустим баз уже 10 штук, и при этом хочется онлайн-синхронизацию (в рамках одной транзакции записать изменения сразу во все базы). Тогда РБД уже не подходит, а com-соединения съедят 10x подключений и лицензий на каждого пользователя.
Подойдут ли для этого вебсервисы, или может средствами SQL реально какую-нибудь репликацию настроить?

(0) >> в рамках одной транзакции записать изменения сразу во все базы

Это не про 1С. К тому же не совсем понятно что должно происходить в случае отказа в одной из баз получателей.
Как будут решаться вопросы коллизий?
ИМХО, 100%-ный онлайн - это фантастика. Это реально только в единой базе.

(6)+ это если конфа УФ

(6) условное оформление не решает всех задач. Быстрый набор и полнотекстовый поиск работают не так, как в полностью переведенной базе
(7) Одна из баз отказала - транзакция откатилась, не?

(9) возьми метадату

(9) >> Одна из баз отказала - транзакция откатилась, не?

Допустим. И как часто у тебя транзакции будут откатываться?
А если в двух базах одновременно запустили какую-нибудь фигню типа группового перепроведения документов или изменения реквизитов, закрытие периода, любую массовую обработку данных.

А скорость отработки транзакций? Это ведь надо дождаться пока во всех 10 базах этот объект будет обработан....

Не. Это точно утопия.

мало данных, для того, чтобы что-то по этому решению посоветовать.

Но что точно советовать тут не получится, так это действия помимо возможностей платформы. А как распределен функционал пользователей и зачем все-все документы раздавать на все базы?

в любом варианте, взаимодействие придется завести через центральную базу, в которой число онлайн пользователей минимально

(4) план обмена(конвертация)+веб обмен.Пиши,договоримся

>в рамках одной транзакции записать изменения сразу во все базы

ловите. наркомана.

Какой в этом прикладной смысл?

(15) >Какой в этом прикладной смысл?

Кроме как сделать работу юзеров АдомЪ, ничего в голову не приходит.

(15) Чтобы не пилить нормальную мультиязычность (5)

(5) Мультиязычные данные перенести из реквизитов справочников в их ТЧ или в РС, доработать интерфейс.

(6) я реализовывал мультиязычнойсть данных через разделение данных в одной базе, можно для разных областей сделать одинаковые ссылки для разных объектов

(17) http://68.media.tumblr.com/451ed9d27812bd2b8471fc2d7a820da9/tumblr_mqgbvsSHah1r0sz5qo1_400.gif

(19) что разделял?

(19) Можно подробнее?

(5) рассматривали ОбработкаПолученияПолейПредставления ?

везде одно и тоже, но везде разные языки.
Как так?

Вафель ты с КД3 работаешь?

(25) нет, у меня ерп. Но еси инужно могу изучить

(0) Не понял, почему нельзя работать в одной базе?

(27) хз... это по отношению к тс, а вот в ветке телепатируют, что там мультиязычность может быть. Только никто не знает, что там на самом деле

(26) >>Но еси инужно могу изучить

Да это понятно, мне вот щас похоже это предстоит, но мне эти обмены еще с КД на 7.7 настокиздели. Вот думаю только у меня так или у кого еще...

(29) а мне наоборот нравились обмены.
Запустил и полчаса-час на мисте сидишь

(30) Это когда у клиента торчишь и потом ему эти часы выставляешь?

(31) я в основном из офиса занимался

у клиента как раз не удобно. на мисте не посидишь - не поймут

(33) да у вас батенька мистозависимость...

(34) ну не работать же )))

(35) Кем надо работать чтобы не работать?)

(36) не поверишь, но можно и одинэсником )

(36) на фиксе именно так

(28) Мультиязычность? В конфах 1с?  Однако... Таких извращений еще не встречал. В принципе, если выходить на мега-корпорации, то фишка, конечно, полезная.  Только есть одно но... Не тянет пока 1с на мега-корпорации.

(38) на фиксе денег много не заработаешь...

(0) однозначно одна база. локализация. а насчет данных нужно больше информации. можно сделать структуру данных, чтобы в и одной базе хранить.

(0) если есть бюджет, то можно посмотреть в сторону софтпоинта, у них есть решение для практически онлайн обмена. Но это стоит денег.

(40) жизнь это не только деньги

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

(22) (44) что-то на подобии, но можно и без перелогина, просто обработкой менять параметры сеанса.

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

вешаешь подписку ПриЗаписи, где создаешь копию объекта с такой же ссылкой (тут надо еще предусмотреть заполнение документа в другом языке, на ваше усмотрение)

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

на реальных задачах не применял, были тестовые разработки :)

(45) "где создаешь копию объекта с такой же ссылкой"
создаешь копию в нужной области данных

(28) про мультиязычность см. (5)

(45) (46) Все равно непонятно. Объект-то должен быть один, на каком бы языке пользователь ни работал. Ссылка на него везде должна быть одинаковой

(48) почитай про разделение и области данных
объектов несколько в разных областях - ссылка на них одна.
и при смене области данных ссылки не теряются, а объекты разные

(45) > вешаешь подписку ПриЗаписи, где создаешь копию объекта с такой же ссылкой
жесткий изврат

(50) главное не зациклится

(49) ссылка все таки не одна, а несколько
просто УИДы у них одинаковые будут

омайгад! Это (44) же сарказм был!
охщи...

(50) (52) пожалуй разные ссылки, но при смене области данных все отрабатывает корректно.
жесткий изврат, возможно, но это же 1С ;)

(51) на это есть ДополнительныеСвойства

(54) не, 1с тут не при чем - все это в итоге хранится в базе данных
представь, что ты это просто проектируешь на табличках - тот же изврат получится

(56) потом подумаю, не смотрел как 1с реализует разделение на табличках, но больших сложностей не вижу.

по сути делим только объекты, при этом движения не делятся

(19)(45) Круто, спасибо за идею!
(44)Зачем снова делать на английском? Перелогиниваешься, а он уже сделан на английском, т.к. первичные справочники номенклатуры, контрагентов и др. уже переведены

(57) получается, что у тебя в движениях отражаются разные ссылки из разных интерфейсов
например, английский приход 1шт, русский расход 3шт
итого два остатка 1 и -3, а на один = 2

опечатка: а не один = 2

(59) приход и расход на обоих языках одновременно

(61) он написал, что движения у него не делятся

(62) не может быть такого.
Делаешь копию, но не проводишь что ли ?

(63) я не знаю что у него там за круговерть

Смахивает на геморой.
Может проще поцепить нужные данные через внешние источники а не синхронизировать их постоянно?

(61) (63) (64) подумал. ну да движения, тоже двойные :)

пофантазировали и хватит. тут куча нюансов всплывает.

(5)
> Это теоретический вопрос
изыскания на пути к сделатьфсе, не?

(66) тут только ты фантазировал

(0) так ты расссматривал ОбработкаПолученияПолейПредставления ?

(68) да конечно

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

(71) два документа = 2 ссылки = 2 набора записи.
Никак по другому платформа не умеет

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

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

(69) Да, рассматривал. В некоторых случаях помогает для перевода наименования, но далеко не идеально

(74) в чем именно неидеальность?

(75) Автоподбор работает не так, в форме списка вместо наименования надо выводить ссылку (чтобы она перечиталась по представлению), итд

(45) Копию объекта делаешь через ЗаполнитьЗначенияСвойств() или Скопировать() делаешь? Скопировать() копирует и разделитель, а как его сменить, не понятно...
ЗаполнитьЗначенияСвойств() со сменой параметра сеанса работает, но с учетом отдельной обработки табличных частей работает медленнее

(76) ЗаполнитьЗначенияСвойств()

(76) >в форме списка вместо наименования надо выводить ссылку

Похоже, что нужно хранить значения полей на других языках. Как вариант, хранить значения полей на других языках в регистре сведений, в запросах с ним соединяться и выводить данные на нужном языке. Вроде не сильно сложная доработка получается.

(76) > Автоподбор работает не так
Неужели допил автоподбора и прочее подобное сложнее РИБа и разделения данных?

(76) можно поля с наименованиями на других языках добавить в поля поиска

(79) Допили ка автоподбор в поле отбора скд, которое пользователем добавлено. Может быть и можно, но вариантов, где допиливать автопотбор что-то слишком много

(81) для этого есть ОбработкаПолученияДанныхВыбора

(73) если запись одна то какой регистратор в этой записи, например при такой выборке
"ВЫБРАТЬ Регистратор ИЗ РегистрНакопления..."
?
Или это зависит от текущего разделителя?

(83) там ссылка, ссылка при хранении данных это ГУИД, он одинаковый, по сути у двух объектов одна ссылка.
у записи там регистратором является ссылка, а ее представлении и объект соответствующий ей зависит от параметра сеанса отвечающий за разделение данных.

(84) очень мутнохитрая схема
вы не находите?

(85) где и в чем муторность?

(86) если говорить только про то, что одна ссылка по сути ссылается на больше чем один объект в базе - это неочевидное ипользование платформы, которое может сломаться при к.н. очередном обновлении платформы

(87) много что может сломаться, если откажутся от поддержки какого-то механизма.
я использую конкретный механизм платформы, это не баг

http://catalog.mista.ru/public/571770/ решил оформить идею

(88) если говорить про поддержку механизма то тут риски минимальные
у тебя же используется недокументированная возможность

но это только то, что касается ссылок
а по сути, такое решение мне видится, как способ вместо того, чтобы структурно организовать данные, используется дублирование объектов
хотя, за пытливость ума, конечно +

(89) И как оно будет работать при обмене?

(90) я смотрел реализацию 1с данного механизма, тяжело найти документацию по принципам хранения данных.
http://howknow1c.ru/programmirovanie-1c/razdelenie-dannyh-1s.html тут написано про одинаковый ГУИД, при хранении данных ссылка это ГУИД. больше не могу что-то добавить.

(92) какой обмен?

(92) все будет как настроите обмен, если в крации

(95) Уточняю. Что будет в файлах выгрузки? Про РИБ уже молчу...

(93) как именно хранятся данные есть статья на итс
но в в (86) я написал не про это

(96) не хочу проверять обмены (даже РИБ), остальное ответил раньше, как настроите выгрузку, то и будет выгружаться.

можно ли выгрузить общий реквизит и как? не знаю.

(97) https://its.1c.ru/db/metod8dev#content:1798:hdoc
эта статья или есть другие?

(99) тебе мало что-ли?)

(мысли вслух, имхо)
РИБ и голову не ломать. Механизм известный и известны все его недостатки и как их решать. Ах, да, "нет онлайна" :) Можно подумать, что он есть сейчас в 10-ти базах Работают же сейчас и ничего, решают возникающие проблемы в рабочем порядке.

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

Включение разделения данных не изменяет структуру хранения данных - доступ к данным или изначально программно так и так "разделен", или в таблицах изначально присутствуют "разделители" (например, "_DataSeparationUse").

Забудь про "одинаковый ГУИД" и попытки "работы" с такими объектами - отключение уникальности ещё не означает, что такие ГУИДы не создадут проблем в будущем.
Что будет если в объекте изменят значение у реквизита-разделителя и объект попадёт в область, где у него уже есть брат-близнец по ГУИДу?

(101) >> Что будет если в объекте изменят значение у реквизита-разделителя и объект попадёт в область, где у него уже есть брат-близнец по ГУИДу?

Давай проще, запретим изменение реквизита-разделителя.

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

(98) Красиво ушел от проблемы, с молодецким таким журчанием =)

(104) посыпь песком, разберись с проблемой, которую сам придумал :)

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