Добывать данные через OLE  из другой базы, медленно + различные ограничения (с длинными строками проблемы там и другие есть). Если попробовать так:
Через OLE подключаемся к нужной БД, там запускаем глобальную процедуру по выгрузки данных в БД Sqlite (через обработку ожидания).
В основной базе подключаемся к этой  же БД Sqlite и читаем данные. Сделать таблицу куда будут помещаться имена выгруженных видов объектов. Основная база мониторит  эту таблицу и при появление новой строке начинает грузить таблицу.  OLE процесс выгружает данные, основной процесс грузит.  Какие ЗА и ПРОТИВ? Взлетит или нет?

А чем РИБ не подходит?

(1) Суть задачи немного другая, при переносе не которые реквизиты меняются, есть и другие моменты

(1) + это разовые обмены, а не на постоянной основе

(3) Чем КД не подходит?

(4) Что такое КД?

(4)ее учить надо, велосипеды с оле намного веселее. Особенно когда после тебя приходит другой программист и разбирает их. Ох как ему весело!

(5)конвертация данных.Конфигурация такая есть

Взлетит. Против.
С сайтом один такой похожий обмен сделан, только через мсскуль. Работает.
Насколько это целесообразно для обмена между базами 1С - есть сомнения, но взлетит если правильно сделать.

(8) Почему против ?

(0) подключайся как к внешней базе, метаданные присоединяй через 1с++, и тяни напрямую.
И да, класс "прямой запрос" вроде мог работать с другой базой тоже.

(8) Есть 3-основных подхода:
1)РИБ
2) Заходить в одну базу выгружать данные в промежуточный файл, заходить в другую загружать.
3) Через OLE
Ну про КД  нечего не могу сказать, незнаком.
Чем такой нестандартных подход хуже, который я предложил. Пользователь  запускает обработку в одной базе, без сложных настроек и беготни из одной базы в другую. + думаю скорость на порядок должна быть больше. Перебор  ОЛЕТЗ-ки или ОЛЕ справочника в раз 10 медленей работает, чем не ОЛЕ

(10) Не совсем понятно "подключится как к внешней базе"

(5) нахрена это самосвал в клюшках? я понимаю его использование в обменах 8-8 где восьмерчники схемы данных не знают/не помнят и за любым чихом в КД лезут...

(13) ну, при должном навыке - гораздо проще.
Ну и это уже стандарт, хочешь ты этого или нет.

(13) Могу продать резиновую кувалдочку (сегодня в магазине видел).

(12) http://www.1cpp.ru/docum/html/ODBC.html#setdatabase

(15) XNJ, GJ K,E&

(17) Составишь компанию? Одному там скучно

(16) Тут для SQL версии по-моему только

(19) тут для метаданных. а уж используя подготовленный запрос, можешь обращаться и к чужой базе.
Ну и посмотри класс ПрямойЗапрос, там _вроде_ было сделано и для 1склайт, но не гарантирую

(20) ок спс

(20) ошибаешься, скульлайт работает только в родной базе.

Если нужен для дбф запрос к сторонней базе, то всё лепится через фоксовый провайдер.
И типизацию можно прикрутить, при желании и метапарсер будет работать и .. что хочешь.
Ну и по большому счету, особой разницы нет, куда запрос лепить, в скулеву базу или дбф.

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

(23) ээ.. а че за страничка ? :)

(24) "911" не твое?

(25) не.. это вроде КонецЦикла делал, могу ошибаться

(26) ну тады ой.
http://1c911.by/stati_1s/statya-zaprosy-v-1s-k-dvum-bazam-odnovremenno-dbf-ole-db.htm

А код, для синхронизации, валялся на форуме 1cpp, я его только модернизировал в своё время чутка.

(0) Все равно хотелось бы услышать по теме. За и Против предложенного метода. + распараллелить выгрузку и загрузку

(29) http://ic.pics.livejournal.com/sazhnikov/42871788/867190/867190_900.png

Оле вообще зло.
Проще брать готовые решения. Уриб, например, для отслеживания изменений, МОД для отправки этих изменений.
Усё.

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

(31) Зло - это деньги. поэтому всегда зла не хватает. а оле - ну, что-то типа (30)
Не, использовать, конечно, можно. но нуегонафик

(33) не, ну разово, оля вполне себе, но на постоянной основе - в печь.

(31) В моем примере ОЛЕ одну функцию глобальную запускает, а не лопатит всю базу. Такой обмен не постоянный, так что Уриб не катит. Перенести данные с одной БД в другую и месяц по-мониторить  изменения в старой базе и обновить в новой.

(30) Чтоб еще немного аргументированно

(34) разово -да. но и то если на одном сервере...

(36) опыт.

(11) Варианты 1 и 2 по сути одно и тоже

хочешь скорости - смотри в сторону сервисов веб или хттп илои одата

(35)А как отслеживать внесенные изменения будешь?

(39) ценность РБД - в автоматической регистрации...

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

(41) таблицу соотвествия создам в той же БД SQLite. Мне пока нужно  отслеживать только новые объекты. две колонки ID старой базы и ID объекта в новой базе. В этой таблице хранить ID  старой базы и соответ. ID новой. При появлении нового объекта в старой базе смотрит в этой таблице наличие с таким ID, нет создается новый

(44)Ну так а че бы не начать писать тогда уже свою "убийцу 1с"? Все равно уже полфункционала переписал.

(44) Таблица соответствия пойдет, можно еще перехватчиком подписаться на на событие ПриЗаписи и сразу писать версию записи в sqlite из базы источника.
Вот только вытягивать данные из 100500 табличек через sqlite будет сложнее, чем через КД - придется создавать таблички.
Должно взлететь. Но попарится придется.

Что-то с многопоточным обменом делали ребята из 2is. Можно их ещё погуглить.