Здравствуйте!

Есть две базы 1С 7.7: первая база - это актуальная рабочая база, вторая база - это копия. Конфигурации идентичные.

Надо сделать обработку, которая из первой базы подключается ко второй базе. Затем с помощью подбора из журнала выбирает нужный документ из второй базы. И загружает его в "свою" базу.

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

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

Возможно, но не совсем просто.

Съемулируй подбор в своей БД

Я бы делал сразу не через тетю Олю, а прямыми запросами.
Получал список, упрощенный до примитивных типов, и из него уже выбирал.
Ну а "конвертация" - стандартно: получаешь из источника содержимое по идентификатору, ищешь в приемнике по ключу... (и далее - рекурсивно для реквизитов ссылочных типов) Особых сложностей не вижу.

(1) А если не совсем просто, то как это делается?

(2) >> Съемулируй подбор в своей БД

Типа загрузить список документов и показать этот список в своей БД?
Правильно я понял?

(5) Да, по оле получаешь доки - номер, дата, поля нужные. Делаешь свою обработку типа журнала (если красиво) или просто  выбор из ТЗ. Ну и переносишь выбранное.

(3) >> Я бы делал сразу не через тетю Олю, а прямыми запросами.

А в чем будет преимущество?
Там ведь данных не много. Всего один документ.

>> Ну а "конвертация" - стандартно: получаешь из источника содержимое по идентификатору, ищешь в приемнике по ключу...

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

Например, если по идентификатору сделать "ЗначениеИзСтрокиВнутр()" - не сработает?
Ведь по идее должно сработать.

(7) Если это копия, то и документы есть в основной базе? А если они есть, то смысл еще раз переносить?

>>Например, если по идентификатору сделать "ЗначениеИзСтрокиВнутр()" - не сработает?

а если в базе ПРИЕМНИКЕ, нет такого элемента?

(7) Преимущество - в удобстве работы. Думать почти не нужно, запросы примитивные, всё на автомате пишется.

Ну если все ссылочные типы в приемнике совпадают с источником - то там и документ переносимый должен уже быть и совпадать :-)

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

Можно хотя бы для справочников оставлять идентификаторы. Т.е. создаешь пустой документ нужного вида, записываешь, а затем заполняешь его полученными напрямую данными, не трогая только идентификатор документа.
Делов на час-два, не больше

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

Я бы сделал через Прямые запросы + Конвертация данных.

(0) На вот, занимайся
https://infostart.ru/1c/tools/102101/
ЗЫ: переделать под sql, как 2 пальца, при желании.

(13) а почему ты решил толкать, а не тянуть?

(15) так было проще всего

Были и поделки, где прямой запрос выполнялся в обеих базах сразу для поиска "битых" ссылок, собирал их в кучку и отправлял.

На форуме сайта 1cpp есть интересное сообщение от Djelf-а:
https://www.1cpp.ru/forum/YaBB.pl?num=1214205575/1089#1089
--------
Фишка 1sqlite в том что не либо, а одновременно!
И подключить можно несколько внешних sqlite баз (не 2 базы 1С 7.7, а только одна база 1С 7.7)
Обращение к базе sqlite, если имена таблиц не пересекаются, можно просто по имени, если пересекаются как "JOIN ИмяСхемы.ИмяТаблицы AS МояПрелесть".

У мне так все интеграции и сделаны, внешняя база в sqlite, поле ID там есть, типизация данных из базы sqlite в 7.7 работает.
Таблицы в запросах из разных источников связываются - нет проблем.
Транзакции тоже раздельные получаются... красота!
--------

Интересно узнать поподробнее: что значит "типизация данных из базы sqlite в 7.7 работает"?
Может кто-нибудь показать пример как работает типизация по ID из внешней базы?
И как нужно записать этот ID во внешнюю базу, чтобы эта типизация сработала?

(17) не нужно тебе типизировать. Тащи примитивными типами.

(18) Почему это не нужно?
В регистрах типы атрибутов - это справочники, перечисления, даже есть документы.
Это все нужно "конвертировать" (то есть типизировать).

Как ты предлагал искать объекты поиском по ID-шникам - это все-таки больше работы по сравнению с типизацией при чтении.
Делать поиск по ID-шникам - это муторно, так как для поиска для каждого ID надо знать какого он типа.

Поэтому все-таки интересно разобраться с типизацией тоже.

С прямыми запросами кстати тоже интересно разобраться.
Если делать прямыми запросами, то как сделать прямой запрос к внешней базе? Как к ней надо подключаться для выполнения прямого запроса?

(19) Тебе еще и движения регистров нужно перетащить по выбранному документу?
А вариант: перепровести перенесенный документ в базе-приемнике - тебе не подходит?

(19) 1. Не нужно потому, что любой ссылочный объект раскладывается до примитивных типов. рекурсивно.
2. "больше работы" - это вряд ли. одна-единственная функция, в которой сравнивается всё, кроме таймстампа.
3. Разбирайся.
4. Разбирайся. У тебя времени было вагон...
5. Читай документацию. https://www.1cpp.ru/docum/html/ODBC.html
---------
будут конкретные вопросы - спрашивай, а в целом тебе уже дали чуть не готовое решение...

(20) Можно перепровести перенесенный документ.
Но в этом нету принципиальной разницы.

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

Из того, что советовали выше, вырисовываются следующие варианты:
1) Прямые запросы.
Но я так и не понял как делать прямой запрос в другую базу. Пример бы посмотреть.
2) Типизация с помощью 1sqlite. Это, как я понимаю, тоже прямые запросы, но уже с автоматической типизацией.
Тоже нужен пример. Без примера - не понятно.
3) Вручную искать по ID-шникам в базе приемнике.
По сравнению с автоматической типизацией выглядит как более трудоемкий способ.
4) Через "ЗначениеИзСтрокиВнутр()". Пробовал - вроде работает. Но интересно и другими способами попробовать.

(17) прямой запрос к разным базам с типизацией делается или в sql через odbc, или в дбф через vfpoledb, для типизации нужно присоеденитьМД. Разименование полей, через @.
Все примеры есть на 1cpp.
Но, тебе рано еще с такими вопросами, раз через 1sqlite пытаешься это делать.

На вот, развлекайся

Процедура Сформировать()
	
	
	рс=создатьОбъект("ODBCRecordSet");
	
	 ТекстЗапроса = "
	|SELECT
	|	СпрНаш.DESCR as КлиентосВЭтойбазе  -- наименование клиентоса в  этой базе
	|	,Спр.DESCR as КлиентосВУдаленнойБазе --наименование клиентоса в удаленной базе
	|FROM $Справочник.Контрагенты СпрНаш (nolock)
	|left join dataBase2.dbo.@Справочник.Контрагенты Спр (nolock) on СпрНаш.Code = Спр.Code
	|";	
	глМД = СоздатьОбъект("MetaDataWork");
	ТекстЗапроса=глМД.ОбрМетаСКЛ(ТекстЗапроса);
	глМД2 = СоздатьОбъект("MetaDataWork");
	ПутьКБазе2 = "D:\полный путьк базе данных\";
	глМД2.ПрисоединитьМД(ПутьКБазе2+"1Cv7.md");
	ТекстЗапроса=СтрЗаменить(ТекстЗапроса,"@","$");
	ТекстЗапроса=глМД2.ОбрМетаСКЛ(ТекстЗапроса);
	
	Т = рс.ВыполнитьИнструкцию(ТекстЗапроса);
	Т.ВыбратьСтроку();

КонецПроцедуры

(24) Это не 7.7

(25) она, она..+1cpp

(26) Я понимаю, что это семёрка на стероидах. Мерзость

(27) расскраска кода, как делается нынчче ? Автомата нет ?
Ручками тегом ?

(22) напиши на инфостате О-Planet, поклянчи у него обработку 2003 года, по переносу между базами, там как раз и через оле, и через ЗначениеВСтрокуВнутр/ЗначениеИзСтрокиВнутр. Быстрее будет.

(28) тег PRE из правой панели Оформление

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

(24) да [ему] проще вытащить из одной базы одним запросом, из другой базы этим же запросом, и сравнить результат...
А еще проще - (29).

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

(22) Вот есть готовое и бесплатное
https://infostart.ru/1c/tools/14395/

(0) "И как потом быстро и удобно "конвертировать" все ссылочные реквизиты исходного документа из базы-копии"
...и ссылочные реквизиты ссылочных реквизитов ссылочных реквизитов...

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

Конвертация данных решает все вопросы переноса данных. Или в этой ветке другая религия в почёте?? ))

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

(38) А вот не соглашусь! Ибо пройдены были этапы разных способов переноса данных, условно говоря, "от А до Я".

К конвертации надо дописать удобную оболочку и всё гоняется туда-обратно весьма шустро. Правила писать недолго, дня 3-4, а вот раскуривать автору рекурсию по метаданным - это то ещё занятие. Да ещё есть рекурсивные ссылки в данных... В общем - надо ОДИН раз научиться пользоваться Конвертацией. Время сэкономит в любом случае очень много.

(37) Это лично Ваша религия. Вы вправе её пропагандировать, но лично моё мнение, что КД - отстой. Не зря же они выпускают мажорные версии, то есть сами признают, что предыдущая версия - отстой.

(37) какая конвертация? КД2, на восьмерке? зачем она нам..?

между одинаковыми базами вполне себе гоняется универсальной выгрузкой/загрузкой XML, с выбором подмножества объектов, с зависимыми ссылками итд.

(40) да ничего придумать не смогли, вот и рожают дальше наследников от клюшечной конвертации КД 1ой версии

(39) То, что КД нужно уметь пользоваться - абсолютно согласен. Если бы конфиги были не идентичными (наследниками) - КД абсолютно верное решение.
Но тратить неделю (правила+оболочка) для разовой задачи...
Впрочем, ТС пропал - может, сделал уже каким-нибудь Универсалом...

(44) >> Впрочем, ТС пропал ...

Нет, я не пропал.
Я здесь. Читаю ответы-обсуждения, думаю, пробую.

>> ... может, сделал уже каким-нибудь...

Пока на небольшом примере сделал с помощью "ЗначениеВСтрокуВнутр()" - "ЗначениеИзСтрокиВнутр()".
В принципе удобно, не надо никаких рекурсивных обработок ссылок до примитивных типов.
Неудобство этого метода в том, чтобы надо отдельно делать выгрузку и отдельно загрузку.
Как я понимаю, через подключение по OLE к другой базе это не сработает, поэтому данные надо передавать например через файл.

Но у меня уже интерес чисто "теоретический".
Какой способ будет удобнее?

(24) Вот в примере с прямыми запросами....
Зачем мне наименование контрагента?
Мне бы получить ID и автоматическую конвертацию\типизацию элемента справочника-источника в элемент-приемник.
А как это сделать прямым запросом?

Также интересно разобраться со способом через 1sqlite.
Djelf куда-то пропал, нигде не отвечает :(
Заинтриговало его сообщение о типизации (17). Как это делается?

(47) Никак. Если ID из одной базы то в другой базе с отличающимися ID типизировать никак.
Разве что по коду или наименованию сначала искать, а потом типизировать, но это не  надежно.
Генерить uuid можно и искать по uuid, но перелопатить обе базы придется...

(48) Так ведь у меня обе базы идентичные. Все ID должны совпадать.

(49) А можно спросить - зачем из одной базы лезть в другую, если они идентичные?

(50) Сделали копию рабочей базы.
В рабочей продолжили работать, удалили документ. А теперь его надо "восстановить" из базы-копии.

(51) Так тебе нужно с тем же ID его "восстановить"? Тогда УРБД. Главное, чтобы потом не оказалось чего-то еще удаленного.

(45) Для обмена тетей олей - в базу в глобальник экспортную фукнцию типа

Функция СтрокаДляОли(объект) Экспорт
возврат ЗначениеВСтрокуВнутр(объект)
КонецФункции

(46) тебе дали ПРИМЕР как подключиться прямым запросом к другой базе, и вытянуть оттуда КАК ПРИМЕР наименование контрагента там и тут. ты же сам просил пример?
Автоматической конвертации не будет. Ну либо если гарантируешь, что справочники совпадают, то (10).3, или вообще напрямую в базу пишешь, чтоб воссстановился документ с тем же идом (и затем проводишь).
а типизировать можешь и внутри, если уж иддефы совпадают.

(47) Как я и предлагал в (3). Для объекта получаешь нетипизированные данные оттедова и отседова, проходишь по ним и сравниваешь. Для каждого реквизита ссылочного типа делаешь то же самое. Если реквизиты совпали, значит, всё, на что есть ссылки, совпадает, док можно пейсать в базу.

(51) У тебя что, не метят, а сразу удаляют наглухо?

(52) я уже предложил в (33).

(51) п...ц готовая поделка в (13) лежит, на тебя смотрит

Это хардкор, а не тема.
8 дней размышлений как перенести один документ...
5 летний ребенок уже научится бы и набил это один потерянный документ.

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

(55) >> 8 дней размышлений как перенести один документ...

Какие 8 дней?
Я же выше написал: у меня уже на следующий день все работало через "ЗначениеВСтрокуВнутр".

Вы просто мой вопрос не слышите, и не отвечаете на него.
Мне интересно разобраться с типизацией через 1sqlite. Выше я дал уточнение: ID-шники одинаковые в базах.
Ты расхваливал этот вариант, писал что это просто "красота". Вот я и хотел понять какая там "красота" в этом варианте.
Ответа так и не последовало.

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

(40) Это не религия, это закономерный результат. Как бы странно не звучало "два часа потерять, за 5 минут долететь", но в данном случае так оно и есть. И это НЕ пропаганда! "Пропагандой" можно назвать идеи получения данных прямыми запросами без обсуждения типизации, поиска в базе и т.д. и т.п. Смотреть на выпуски версий "мажор-немажор" - а зачем, когда и так всё работает? Это не отстой! Мало того! Если доработать своими руками КД2 до работы с sqlite с нормальным поиском по произвольным реквизитам, то будет весьмааа интересно )))  

(41) База на 7.7, там нет 8-ки
(42) Прикинь, универсальнная выгрузка XML написана на КД )))
(43) Ты не в теме ))
(44) Я тоже думал, что быстрее текст/xml/com-универсал/и т.д.  Да фих там. Пока не разберешься во всех кишках, нормальной работы не будет. Поэтому надо один раз разобраться с универсальным инструментом, чтобы нормально с ним работать
(49) Это только кажется, что ID должны совпадать. Редактирование документов всё равно будет.
(53) А в Конвертации это будет автоматически. Мало того! Можно ведь накуролесить многочисленные алерты, логи, хелп-файлы и т.д. и т.п.  ;) ;)

(58) В конвертации же нету поиска соответствия объектов ссылочных типов по внутреннему ID.
Или я ошибаюсь?

(59) что мешает сделать?
И вторая сторона вопроса - а если иды одинаковые у разных элементов (на одной стороне взаимно переименовали ИП Пупкина и ИП Писькина?)

(60) Будут хреново, ты сам это знаешь...

(58) унутре у КД тот же самый принцип - рекурсивная выгрузка объектов до уровня примитивных типов. Только есть еще и промежуточные правила обработки.
Дорабатывать КД один хрен нужно. (как минимум, писать правила, а как максимум - твои же предложения доработке морды, и по поиску с использованием сиквеллайта - т.е. с осуждаемыми тобой же прямыми запросами). каждому овощу свой фрукт - в смысле, каждому инструменту сое применение, и каждой задаче свой инструмент. Использовать на каждый чих КД - это как использовать на стройке мультитул лезермановский - вроде в нем и нож, и плоскогубцы, и отвертка, и пилка, и напильник - только и режет, и пилит, и кусает он одинаково хреново.

(61) ну так и я о том же - если надо "просто перенести", то обработка "вытянуть данные, и рекурсивно сравнить"  делается за пару часов. Если "вытянуть и записать без сравнивания" - то еще быстрее. А если искать (по некотороым признакам - типа, не нашли по коду и наименованию - ищем по ИНН), создавать при отсутствии, да еще кэшировать загруженные, да еще регулярно это делать, да по расписанию... - тут КД лучше применить.

(57) Я ничего плохого в отзыве не написал.
Я просто назвал причину - это мой вопрос, на который еще не было ответа.

(59) Да, нету. Но можно просто сделать свою функцию, которая будет искать по твоему алгоритму, по любому алгоритму, по любому полю и в любом месте. Функция может быть как встроенная (в правила конвертации), так и во внешних инструментах.

(62) Рекурсивная выгрузка - это ессно есть всегда и везде. Выгрузить не сложно, загрузить сложнее ;)  По поводу "морды" - это сугубо УДОБНЫЙ интерфейс для пользователя. У нас девчата накидывают накладные на отправку и жмут одну кнопу. Всё. Получение так же - просто кнопка. Про sqlite - это была моя идея доработки, ибо конфа КД настолько открыта для доработок - аж руки чешутся. Именно sqlite удобна для поиска по реквизитам. Ну, это я так - идеи вслух. На самом деле ничего там сложного нет, ВСЁ решаемо. Один раз решил и постоянно пользуешься уже не думая.

И "за каждый чих" не согласен ))) А тем более за "хреново пилит, кусает" ))) При одинаковых конфигурациях всё делается "до обеда" )))  ЧЕсс слово!!! ))

Опять же - удобный интерфейс для работы. Ессно надо один раз разобраться и потом оно работает )) Просто кидаем кучу объектов для выгрузки, не смотрим - пересекаются они или нет, и они автоматом выгружаются. Всё весьма шустро работает ))

(65) Если честно, в силу возраста, я разбирался с этой кухней месяц, потом ещё месяц более-менее вникал в нюансы. Если бы не уволился, то ещё что-нибудь много интересного узнал )))

КД  - это ВЕЩЬ!!!