Итак, задача такова. Есть две базы на 8.2 (8.2.17): УТ и БП. Данные перегружаются из УТ в БП. После этой операции нужно провести сверку остатков и оборотов по складам. Нужно эту самую сверку автоматизировать. Идея такая: обработка, которая запускается, например в БП, подключается к УТ, формирует таблицу по движениям и сравнивает с оборотами 41 счета. Теперь вопрос: как лучше подключаться (по ole или через com или ещё как-то) - чтобы была оптимальная скорость получения и обработки данных и возможность получить необходимые для сравнения данные из таблиц партионного регистра? Обе базы файл-серверные. Подскажите, какой вариант больше подойдет для задачи и желательно объяснить разницу и почему лучше)

(0) ком
без комментариев

(0) А почему бы не выгрузить остатки, к примеру, в текстовый файл - а затем этот текстовый файл в другой базе загрузить?

(2) Этот вариант на случай, если не получится соединяться напрямую

(3) интересно а что может этому помешать?

(3) А почему нужно именно прямое соединение?

http://kb.mista.ru/article.php?id=35

Потому что оно лучше кривого.

(4) Например, использование не Виндоуз на серверах 1с.

(4) Например, не получится. Не работал с этим, не писал таких обработок
(5) Через текстовый или ексель дольше: выгрузить, загрузить, сравнить..

(8)В условии: "Обе базы файл-серверные". Стало быть, серверов 1С нет.

(9) у нас через com написана такая обработка. Три базы. Работает быстро.

https://dl.dropboxusercontent.com/u/12484308/СверкаНоменклатуры_УТ_БП82.epf

на и не мучайся. Лишнее выкинешь из обработки. Запускай из под УТ

(11) Спасибо, какие базы? Какие функции выполняет обработка, что значит быстро? Замечали за какое время полный цикл проходит, примерно, какая операционка?

>>как лучше подключаться (по ole или через com или ещё как-то
)

пример на первые два варианта приведите.

(12) Спасибо, посмотрю

(14) не понял вопрос

(1) А теперь вспоминаем что есть OLE и что с COM у них общего. :)

(17) что?

(18) Что, что? Ты почитай. Двумя словами. COM - это некая модель, вполне себе абстрактная, а OLE частная реализация этой модели. Т.е. OLE - это и есть COM. :)

Можно например почитать вот это: wiki:Microsoft_Component_Object_Model

(19) благодарю за разъяснение

В данном случае человеку достаточно COM соединения для вытягивания остатков, нет смысла использовать возможность OLE для работы с интерфейсными объектами базы источника.

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

(22) Я могу ошибаться, но таки есть мнение, что метод Новый COMОбъект, при подключении к другой 1С использует OLE. :)

(23) да не просто дольше а еще этот самый excel нужно ставить. Зачем спрашивается костыли городить.

Если уж и использовать файл, то xml однозначно.
Получил остатки, выгрузил в таблицу, сохранил таблицу в xml и усё.

Ну и как бы COM/OLE не самый быстрый в мире интерфейс. Зачастую через текстовик выходит быстрее.

(25) А зачем Ёксель? У меня его вообще не было еще 2 недели назад. CSV или XML - наше все.

всем спасибо за мнения и комментарии, буду пробовать, экспериментировать с обработкой.

(25) А зачем xml, если есть plain text? Структура-то таблицы - проста. Причём это - _таблица_, с фиксированным количеством колонок и т.д.

(29) Новые слова)

(29) Все-таки xml бывает полезен более чем просто текст с разделителями. Удобнее структурированные объекты переносить. Например документы, они есть сами вообще, у них есть шапка и есть ТЧ, можно конечно сплошным текстом, но xml просто удобнее.

(31) Не спорю, что xml полезен. Но в данной задаче - перенос одной таблицы - plain text проще формировать и проще разбирать.

(32) Это да, соглашусь. Остатки по номенклатуре - это плоская таблица. Нафиг все эти OLE и XML. Плоский текст с разделителем - проще некуда.

(32) Единственное, что перенос надо делать в два этапа. Сначала номенклатура, потом по ней остатки. Но с другой стороны, это даже лучше. Сначала номенклатуру перенесли и проверили, а потом уже тащи остатки.

(34) тут не перенос, а выгрузка движений для бухгалтерских отчетов и операций. Сверка идет по движениям и остаткам по складам, если находятся расхождения, по регистраторам.

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

(35) Да какая разница? Что такое таблица, как она выглядит в физическом виде и текстовом представляешь? Если нет, то открой Ексель и познай дзен. :)

(36) Я делал подобное через текстовик. Одна база выгружает затребованные данные, другая подгружает и анализирует. Лично мне так было проще. Если предполагается, что работать с этим будет рядовой юзер, то чем меньше телодвижений, тем лучше, т.е. таки COM/OLE.

(38) не рядовой юзер, но цель - максимально автоматизировать и ускорить. Одна обработка, минимум операций и посредников, максимальная скорость сверки и выдачи результатов.

(38) Я тоже предпочитаю текстовые форматы - когда с ними я сам работаю. Но когда будет работать кто-то, тем более - бухгалтер и т.п.

(39) Ну блин тебе кучу вариантов набросали - сам решай.

(41) я так и сказал. Спасибо за советы и опыт сверок. Буду экспериментировать.

(38) Вместо текстовых файлов проще использовать XML через ФобрикXDTO. Например данные выгружаются по текущей фабрике.
Выгружается схема.И этой схеме загружаются в другую или наоборот. Можно создать свой пакет который использовать в обеих конфигурациях. Можно автоматически сгенерить v8: XSD схема программно с нуля.

(43) Не всегда это проще.
1С ведь совсем не зря поддерживает несколько различных способов интеграции.

(44)  Например? Через фабрику ты пишешь и читаешь обращаясь к объекту через точку. С текстом  нужно оперировать позицией в строке. Для простых случаев проще использовать ДБФ. В тексте нужно экранировать разделители строк. Итд. С XML проще, но его минус излишний размер, который больше влияет на передачу. Хотя   с моей точки зрения проще использовать специально заточенную для сериализации БД. Но это уже отклонения, в которых нет не только в 1С.

(45) Ну вот зачем мне фабрика XDTO, если я прекрасно могу без неё обойтись?
И зачем мне с текстом оперировать позицией в строке?
DBF - тоже замечательно. Но если у меня простая фиксированная структура, которую я читаю/пишу строго последовательно, то зачем DBF (который, к тому же, не всегда удобно смотреть)?

Для каждой задачи есть свой наиболее удобный инструмент. Который вовсе не обязательно будет наиболее удобным для другой задачи.

Хотя, конечно, воробья и из пушки пристрелить можно.

+(46)
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html

Дбф  как раз для фиксированных структур, текст обычно нужен для неструктурированной информации. А самым подходящим будет тот, на который нужно затратить минимум усилий, если конечно не стоит задача по скорости передачи данных.
Кстати есть еще и http://en.wikipedia.org/wiki/Protocol_Buffers

http://ravendb.net/docs/intro/ravendb-in-a-nutshell

Данные в RavenDB хранится без схемы как документы JSON

Для сериализации предпочтиетльне такая организация . Каждый тип хранится в своей таблице. Поля имеющие составнын типы хранятся в виде структуры тип (номер таблицы) и номер записи в таблице. Ссылки на известный тип просто запись в таблице, для значений переменной длины в блоб таблицах. Единственно, что нужно организовывать в памяти ввиде Хэш таблиц слежение за добавленными объектами. Это использование памяти.

"А самым подходящим будет тот, на который нужно затратить минимум усилий, если конечно не стоит задача по скорости передачи данных" - вот именно.
Тогда почему Вы столь упорно настаиваете, что нет задач, при которых такой самой подходящей структурой является plain text?
Ведь не всё же ваяется на века. Бывают и задачи, когда нужно быстро сделать сейчас и закрыть тему.
XDTO - замечательная штука. Но... Надо как минимум описать структуру пакета (кстати, где она описывается? не в конфигурации ли? ой, а у меня там сейчас пользователи работают...). А

ТипСтроки = ФабрикаXDTO.Тип("http://www.qqq.qq/";, "СтрокаТабл");
СтрокаТабл = ФабрикаXDTO.Создать(ТипСтроки);
СтрокаТабл.Ид = Строка(СтрокаТЧ.Номенклатура.УникальныйИдентификатор());
СтрокаТабл.Наименование = СтрокаТЧ.Номенклатура.Наименование;
номенклатура.Остаток = СтрокаТЧ.Остаток;

смотрится лишь чуть лучше, чем

ВывестиПоле(Текст,Закавычить(СтрокаТЧ.Номенклатура.УникальныйИдентификатор()));
ВывестиПоле(Текст,Закавычить(СтрокаТЧ.Номенклатура.Наименование));
ВывестиПоле(Текст,Строка(СтрокаТЧ.Остаток));

+(49) То же самое относится и в DBF (который иногда ничем не лучше CSV). Можно и в JSON сериализовать вместо XML - очень удобный формат. И т.д. и т.п.
Я ведь не отрицаю, что все эти технологии полезны. Более того - сам ими с удовольствием пользуюсь.
Мне лишь непонятна столь резкая неприязнь к plain text.
А ещё я с удовольствием хожу пешком - на небольших расстояниях это удобнее, чем автомобиль.

(19) Садись, два.
Пока сидишь - подумай, почему в OLE можно открыть форму приложения, а в COM низзя. )))))))))))))

(51) Садись кол. Я написал, что OLE - это частная реализация COM и не более того. :)

(50) Та я как раз пользуюсь всеми форматами. По поводу описания пакета, то его можно описать хоть где и не только в текущей конфигурации и необязательно в 1С. Есть схема XDTO которую можно создать и программно v8: XSD схема программно с нуля.

и просто подгрузить СоздатьФабрикуXDTO(ИмяФайла);

Говоря проще, не означает универсально. При том, что данный подход в этой ветке не проходил. А чем пользоваться в итоге каждый выбирает сам. В CSV роблемы с разделителями строк, которые нужно экранировать. в ДБФ поля имеют одинаковую длину. Но с ним плохо работать например со строками которые могут иметь длину от единицы до мегабайтов. Все зависит от ситуации. А загрузкой выгрузкой текстов я занимаюсь очень давно вплоть до генерации загрузок выгрузок как в текстовом и прочих форматов. Но начинающим проще все же начинать с ФабрикаXDTO. А там из приведенного тобой примера не хватает чтения и здесь Объекты XDTO выглядят лучше. Ну это уже на вкус и цвет.

(53) Экранировать символ - это проблема?

(54) Нет не проблема. Но это дополнительные движения и об этом нужно помнить работая с текстом. И соответственно при чтении нужно об этом помнить.
Либо поступать как при бинарной сериализации указывая длину строки, но это уже получается не текстовый файл с которым 1С не умеет работать.
Еще раз пусть каждый выбирает, что ему лучше. В большинстве случаев проще использовать ФабрикаXDTO.

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

(0) запуск фонового задание. которое вернет результат в другую базу или все ок или фиаско