COM-соединение, как туда "закинуть" таблицу значений #785657

Доброго времени суток! Есть вот такой код: 1C]     Запрос = Новый Запрос("Здесь неинтересный текст запроса");     Док.Движения.Продажи.Записать; [/1C] Но так не работает. Говорит "Несоответствие типов (параметр номер '1')" к строке где происходит загрузить. Я так понимаю, что Док на той стороне не может знать про таблицу значений на этой. Как бы это сделать малой кровью?

Правильно ругается. У тебя поди и запрос берет данные из текущей базы? А ты их во внешнюю базу 1С передать пытаешься.

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

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

попробцуй значение встроку внутр в КОМЕ. Строку получить сздесь и значение из строки внутр тут

Очень просто. Что именно тебя смущает? Действительно, как то не подумал сразу.

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

на большой таблице не взлетит. Использовали ЗначениеВФайл. Потом файлик передавали в другую базу. Но таблица была с примитивными типами

А какая может быть проблема если таблица большая?

>> Очень просто. Что именно тебя смущает? Ты хотя бы понимаешь, что ссылочные объекты твоей базы - это ссылочные объекты только твоей базы, и более никакой? Или у тебя в ТЧ документа реквизиты только примитивных типов?

Я понимаю, что такое ссылочный тип. Представь себе. И что тут нет никакой магии и в другой базе я могу сделать точно такой же объект. Я повторю вопрос: Что тебя смущает? Если ты не в курсе то бывают всякие там РИБ. Где базы то вроде разные а объекты одинаковые.

падало с ошибкой. Сейчас уже не вспомню с какой, но обошли именно передачей через файл

Это уж насколько БОЛЬШАЯ таблица должна быть? Передавал таким образом десяток тысяч строк без проблем.

Так у тебя значит именно этот случай? РИБ и одинаковые ссылки?

30 колонок ~60000 строк

Нет. Риб для примера. Проблема с одинаковыми ссылками на моей совести. В смысле тут понятно, что надо делать.

Первое, что в голову приходит - восстановление документа из бэкапа :)

Если у тебя документ COM-объект, то и результат запроса, который ты выгружаешь в ТЗ, тоже должен быть COM-объектом.

Серьезно? Сходи почитай , что ли...

Ну тогда через файл.. какая в принципе разница?

Тут.ЗначениеВСтрокуВнутр, Там.ЗначениеИзСтрокиВнутр. Про ссылочные типы уже писали...

Наверно вот с этой ошибкой падало: по причине: bad allocation

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

Там так то, нечего ломать, простой достаточно формат.

Конвертация данных 2.1 для этого и придумана.

Отличная штука я тебе скажу. Но вот это я так и не смог победить. Там и другие были ошибки. Если включать/выключать разные объекты. Поэтому частично используются ручные переносы. Если знаешь как победить, буду благодарен, но уже в качестве закладки на будущее. Здесь уже вручную написано наполовину.

У меня почему-то работают все правила, которые делал сам. Что я делаю не так?

Посмотрел твою ссылку. Ну что я могу сказать, если вы не любите кошек - вы просто не умеете их готовить. В КД есть свои тонкости, если тупо делать правила помощниками - ничего удивительного, что не получается. Тренироваться же надо.

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

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

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

перечисления тоже нельзя

Мама не разрешает?

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

не передастся перечисление ни под каким видом. Хоть головой о стенку бейся.

в общем так, если есть совпадение ссылок и нет битых, то не нужно никакого подключения к другой БД - достаточно одного СериализаторXDTO, через него получаешь XML строку и из нее же на другой стороне читаешь объект - ВСЕ

в речь идет про конвертацию значений. Перечисления с ее помощью ездят замечательно.

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

ну так с этого и нужно было начинать откуда у тебя уверенность что ТЗ содержит именно те колонки которые нужны набору?

Запрос построен таким образом.

+ у тебя может и получилась ТЗ на другой стороне, но состав не тот

ТЗ тоже можно через сериализатор выкинуть в XML и на другой стороне передав строку из нее восстановить ТЗ

если уж ссылки реально совпадают

Что значит не тот состав?

пока что забей таблицу значений передал на другую сторону?

к Можно, а можно и ЗначениеВФайл как помог в добрый человек. В целом вроде взлетело. Таблица большая, сложно проверить, что все норм переехало.

ну сериализатор бы сразу сказал если что не так

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

это всё сработает, если все элементы уже есть в базе. А если например новая номенклатура или контрагент. Тогда надо всё равно идти циклом по ТЗ, выискивая слово "Объект не найден" и создавать новые элементы. То, что КД делает автоматически.

проще в бэкапе создать док и потом его перенести с помощью выгрузки-загрузки

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

Точно так же, как вы работаете с запросами через "Ком"

Да уже написано все, самый большой справочник в ручном режиме за несколько часов переехал. Остальные частично на автомате. Сейчас все уже ездит самостоятельно. Остались мелочи. В каком месте это проще? Спасибо тебе добрый человек. Проблема решена уже.

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

Спросить реквизиты в источнике? Как то эта таблица туда пришла? Почему не пришли нужные данные справочников?