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

А система репликации не является посторонним ПО? Если ты дашь доступ логину на реплицированную БД, он у тебя будет видеть все те же данные, если бы ты дал ему доступ на чтение в БД 1С этих 10-15 таблиц.
Ну а так, для репликации включаешь репликацию на сервере, создаешь публикацию транзакций для нужной БД, в статьи добавляешь нужные таблицы, создаешь подписку для целевой БД. Все вроде просто. В случае реструктуризации этих таблиц, придется пересоздавать публикацию. На 2000м скуле у меня лично наблюдается редкий баг - рассинхронизация публикатора с подписчиком, которая не обнаруживается механизмом репликации, то есть рассинхронизация не видна, пока не проанализируешь сами данные. Если подписчик и публикатор на одном сервере, такого скорее всего не будет. Ну, то есть, какое-то время придется тратить на поддержку, плюс у тебя будет постоянно висеть сторонний процесс в БД 1С. Какие минусы от этого, думаю, объяснять не нужно.
Но вообще, у меня, например, несколько сторонних приложений читают из 1С: кубы, sharepoint и тд., проблем нет. Каждое приложение использует свою БД, данные из 1С им подгружаются регламентированными заданиями.

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

Создать другую БД. Скопировать туда структуру таблиц. По расписанию запускать процедуру(ы), которые выгружают из 1С либо измененные объекты(используя _1supdts), либо, если небольшая БД, то целиком все таблицы.

alexdd писал(а) 13. Июня 2013 :: 14:24:

это ж УРБД... не подходит мне этот вариант...