Собственно сабж. поискал по форуму, так ничего подходящего не нашёл :( А ситуация следующая:
имеется сервер 1С предприятия 8.0 (не 8.1) и некоторое количество ИБ. Есть задача создания для данных ИБ единых справочников НСИ. Попутно - для ряда баз - еще и журнал документов одинаковый.
Другими словами - есть 2 абсолютно одинаковых объекта типа "документ", один в ИБ "А", второй в ИБ "Б". в ИБ "Б" пользователи не имеют права добавлять/изменять данные и документы. В ИБ "А" - пользователи имеют такое право. Задача: сделать ИБ "А" источником данных, а ИБ "Б" - приёмником этих данных.
То же самое - про справочники.
Сейчас задача худо бедно решена средствами 1С. Но, не устраивает следующее:
1. Репликация данных не в реальном времени.
2. Нерационально.
Сейчас добавление новых элементов в справочник базы - получателя идет при помощи мега процедуры обхода по метаданным (кстати - если кому надо - могу дать). Работает в принципе очень быстро и "полу-синхронизирует" любые боле-менее похожие справочники. "полу-синхронизирует", потому как фактически сей процедур производит быстрое добавление новых элементов справочника. Если де в ИБ "А" поменяли уже существующий - получается не совсем хорошо, т.к. не было придумано ничего более "гениального", чем поэлементное сравнение... :(
Про регистры сведений и журнал документов - совсем плохо. Там только поэлементное сравнение.

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

Самое печальное - возможно скоро потребуется онлайновая синхронизация различных ИБ с 3х разных серверов. Самое печальное - что синхронизация двураправленная, т.е. будет обмен изменениями...
В принципе - для такого случая решение тоже как бы есть, но - оно опять же - быстротой не отличается, ну и COM соединения через VPN как то не хорошо себя ведут. Чего нельзя сказать про SQL DTS....

Кто что посоветует?

Читал и знаю. ИБ "Конвертация данных" - вообще не из этой оперы. Ровно как и планы обмена. Планы обмена работают с УРИБ. В моём же случае (как я описывал в первом посте) - базы разные (это не одна УПП, поставленная в нескольких местах, это именно то, что я сказал - разные базы), и, в этих базах есть одинаковые справочники (по структуре) и одинаковые документы (по структуре). Необходимо до всех жтих баз сделать единые справочники НСИ, и, для некоторых - единые наборы элементов объектов.

chatmПрисоединяюсь к предыдущему посту - "Конвертация данных" однозначно рулит, обработку выгрузки - загрузки можно довести до полного автоматизма. При этом все изменения в базах данных сводятся к несложной процедуре обновления схемы обмена.
Да блин - есть такая конфигурация, настроена она. НЕ КАТИТ, ибо:
1. НЕ ОН-ЛАЙН
2. ТОРМОЗИТ (когда элементов больше 10.000)
3. Неимоверный объем траффика, т.к. происходит выгрузка практически всего справочника, или списка документов
4. конфигурации не типовые.

chatm1. Что тогда такое ONLINE? Сразу после записи элемента в справочник должна происходить репликация или с какой-то периодичностью?
Да. Сразу после записи элемента, этот элемент реплицируется на остальные ИБ и страновится там доступным.

chatm2. Да, при таких количествах тормозит. Но зачем столько таскать за один раз? Любая репликация при больших объемах будет тормозить, ИМХО
Вот именно по этому и появилась задумка, решить всё на уровне сервера SQL. А зачем - например есть у нас торговая площадка РТС, которая генерит платежки по рынку по 1500-2000 штук. Суммы по 10-20 копеек. Необходимо всё, что загрузилось в трейдинг сразу "отреплицировать" на остальные ИБ. Трепанацию 7ки я проводил и такого рода репликацию делал. Всё просто летало.

chatm3. Это решается при настройке схемы обмена - зачем все выгружать?
см. п.2
chatm4. Так для нетиповых как раз эта конфигурация идеально подходит. У нас через эту конфигурацию написаны правила обмена с веб сайтом, например.
Вывод - внимательно RTFM
РТФМ скурил весь. в том числе и на ИТС. Имеющиеся решения не подходят ввиду тормознутости.

Видел реально работающую систему на 1С 8.0 у ОГК-5. Там синхронизация НСИ выполнена средствами SQL. Т.е. такая задача (синхронизация средствами SQL) очень даже реальна. Вот и интересуюсь - как приступить к этому.

LunxВопрос у топикстартера другой - как настроить репликации SQL, сервера так чтобы базы быстро обменивались информацией с возможностью внесения изменений в любом месте, так, чтобы отражалось потом во всех. Автору сочувствую. Я бы старался вначале применить административное решение, а то как-то плохо получиться, если ответственного за изменения нет.
Именно!!!! Административный ресурс, к сожалению, исчерпан. А уровень ИТ департамента не на столько высокий, что бы давать указания всем департаментам - как работать.... :(

andycppА как планируется в сиквеле определять, когда объект сформирован, чтобы перетягивать только сформированный объект 1С, а не какую-то его запись?
ну это как раз не сложно. На таблицы необходимые - триггеры повесить. Нужное имя таблицы тоже научился выковыривать из БД.

andycppВопрос автору - у нас стоит похожая задача, но с меньшими объёмами, на 7.7 - планируем использовать МОД, чтобы не сильно заморачиваться. Или оптимальнее будет DTS? Где на сей счёт можно почитать сравнение подходов и т.п.? (УРБД, МОД, DTS, ...)
честно говоря - х.з. Конечно, самый правильный метод - использование соотв. ИБ, либо COM соединения. НО - в нашей конкретной задаче не подходит. Решение о том, что DTS использовать конкретно у нас продиктовано тем, что есть уже ряд приложений, выдирание данных из которых на шину обмена происходит при помощи DTS. Ну и собственно - ради единообразия и облегчения администрирования - тоже на DTS решили.

Френсис Дрейкhttp://softpoint.ru/products_id4.htm
интересно. будет посмотреть :)

gybsonЛегко делается даже без конвертации данных.
Вариантов 2:
1. Объекты метаданных копипастятся во все конфигурации - быстро.
2. Создается своя поставка с этими объектами - надежно и красиво.

Далее объекты сериализуются и десериализуются стандартными методами 1С. Максимум 16 часов на реализацию, максимум.

Только в этом случае:
1. должен быть ответственных за проведение обновлений
2. Это XML => никакой онлайновости не будет.

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