Имя: Пароль:
1C
1С v8
Гуру 1С, помогите определиться: Com или Ole соединение?
0 bard666
 
31.08.13
15:26
Итак, задача такова. Есть две базы на 8.2 (8.2.17): УТ и БП. Данные перегружаются из УТ в БП. После этой операции нужно провести сверку остатков и оборотов по складам. Нужно эту самую сверку автоматизировать. Идея такая: обработка, которая запускается, например в БП, подключается к УТ, формирует таблицу по движениям и сравнивает с оборотами 41 счета. Теперь вопрос: как лучше подключаться (по ole или через com или ещё как-то) - чтобы была оптимальная скорость получения и обработки данных и возможность получить необходимые для сравнения данные из таблиц партионного регистра? Обе базы файл-серверные. Подскажите, какой вариант больше подойдет для задачи и желательно объяснить разницу и почему лучше)
1 shuhard
 
31.08.13
15:31
(0) ком
без комментариев
2 Rie
 
31.08.13
15:32
(0) А почему бы не выгрузить остатки, к примеру, в текстовый файл - а затем этот текстовый файл в другой базе загрузить?
3 bard666
 
31.08.13
15:34
(2) Этот вариант на случай, если не получится соединяться напрямую
4 Pashkaa
 
31.08.13
15:34
(3) интересно а что может этому помешать?
5 Rie
 
31.08.13
15:35
(3) А почему нужно именно прямое соединение?
6 Pashkaa
 
31.08.13
15:36
7 SnarkHunter
 
31.08.13
15:37
Потому что оно лучше кривого.
8 Кип Калм
 
31.08.13
15:37
(4) Например, использование не Виндоуз на серверах 1с.
9 bard666
 
31.08.13
15:39
(4) Например, не получится. Не работал с этим, не писал таких обработок
(5) Через текстовый или ексель дольше: выгрузить, загрузить, сравнить..
10 SnarkHunter
 
31.08.13
15:39
(8)В условии: "Обе базы файл-серверные". Стало быть, серверов 1С нет.
11 hhhh
 
31.08.13
15:43
(9) у нас через com написана такая обработка. Три базы. Работает быстро.
12 Pashkaa
 
31.08.13
15:43
https://dl.dropboxusercontent.com/u/12484308/СверкаНоменклатуры_УТ_БП82.epf

на и не мучайся. Лишнее выкинешь из обработки. Запускай из под УТ
13 bard666
 
31.08.13
15:44
(11) Спасибо, какие базы? Какие функции выполняет обработка, что значит быстро? Замечали за какое время полный цикл проходит, примерно, какая операционка?
14 mehfk
 
31.08.13
15:45
>>как лучше подключаться (по ole или через com или ещё как-то
)

пример на первые два варианта приведите.
15 bard666
 
31.08.13
15:45
(12) Спасибо, посмотрю
16 bard666
 
31.08.13
15:46
(14) не понял вопрос
17 DEVIce
 
31.08.13
15:52
(1) А теперь вспоминаем что есть OLE и что с COM у них общего. :)
18 bard666
 
31.08.13
15:57
(17) что?
19 DEVIce
 
31.08.13
16:01
(18) Что, что? Ты почитай. Двумя словами. COM - это некая модель, вполне себе абстрактная, а OLE частная реализация этой модели. Т.е. OLE - это и есть COM. :)
20 DEVIce
 
31.08.13
16:03
Можно например почитать вот это: wiki:Microsoft_Component_Object_Model
21 bard666
 
31.08.13
16:05
(19) благодарю за разъяснение
22 Pashkaa
 
31.08.13
16:05
В данном случае человеку достаточно COM соединения для вытягивания остатков, нет смысла использовать возможность OLE для работы с интерфейсными объектами базы источника.
23 DEVIce
 
31.08.13
16:06
(9) "Через текстовый или ексель дольше: выгрузить, загрузить, сравнить.." Отлаживать зато проще. Сразу видно в каком месте ошибка, особенно если данные представляются сильно по-разному в источнике и получателе. Не зря ведь 1С придумала КД, которая таки двухфазная.
24 DEVIce
 
31.08.13
16:08
(22) Я могу ошибаться, но таки есть мнение, что метод Новый COMОбъект, при подключении к другой 1С использует OLE. :)
25 Pashkaa
 
31.08.13
16:09
(23) да не просто дольше а еще этот самый excel нужно ставить. Зачем спрашивается костыли городить.

Если уж и использовать файл, то xml однозначно.
Получил остатки, выгрузил в таблицу, сохранил таблицу в xml и усё.
26 DEVIce
 
31.08.13
16:09
Ну и как бы COM/OLE не самый быстрый в мире интерфейс. Зачастую через текстовик выходит быстрее.
27 DEVIce
 
31.08.13
16:10
(25) А зачем Ёксель? У меня его вообще не было еще 2 недели назад. CSV или XML - наше все.
28 bard666
 
31.08.13
16:18
всем спасибо за мнения и комментарии, буду пробовать, экспериментировать с обработкой.
29 Rie
 
31.08.13
16:26
(25) А зачем xml, если есть plain text? Структура-то таблицы - проста. Причём это - _таблица_, с фиксированным количеством колонок и т.д.
30 bard666
 
31.08.13
16:29
(29) Новые слова)
31 DEVIce
 
31.08.13
16:37
(29) Все-таки xml бывает полезен более чем просто текст с разделителями. Удобнее структурированные объекты переносить. Например документы, они есть сами вообще, у них есть шапка и есть ТЧ, можно конечно сплошным текстом, но xml просто удобнее.
32 Rie
 
31.08.13
16:39
(31) Не спорю, что xml полезен. Но в данной задаче - перенос одной таблицы - plain text проще формировать и проще разбирать.
33 DEVIce
 
31.08.13
16:41
(32) Это да, соглашусь. Остатки по номенклатуре - это плоская таблица. Нафиг все эти OLE и XML. Плоский текст с разделителем - проще некуда.
34 DEVIce
 
31.08.13
16:43
(32) Единственное, что перенос надо делать в два этапа. Сначала номенклатура, потом по ней остатки. Но с другой стороны, это даже лучше. Сначала номенклатуру перенесли и проверили, а потом уже тащи остатки.
35 bard666
 
31.08.13
16:46
(34) тут не перенос, а выгрузка движений для бухгалтерских отчетов и операций. Сверка идет по движениям и остаткам по складам, если находятся расхождения, по регистраторам.
36 Rie
 
31.08.13
16:48
(35) Это существенная деталь - что сверка при обнаружении расхождений сразу пытается выковырять, откуда они взялись.
Тогда - COM.
37 DEVIce
 
31.08.13
16:48
(35) Да какая разница? Что такое таблица, как она выглядит в физическом виде и текстовом представляешь? Если нет, то открой Ексель и познай дзен. :)
38 DEVIce
 
31.08.13
16:50
(36) Я делал подобное через текстовик. Одна база выгружает затребованные данные, другая подгружает и анализирует. Лично мне так было проще. Если предполагается, что работать с этим будет рядовой юзер, то чем меньше телодвижений, тем лучше, т.е. таки COM/OLE.
39 bard666
 
31.08.13
16:55
(38) не рядовой юзер, но цель - максимально автоматизировать и ускорить. Одна обработка, минимум операций и посредников, максимальная скорость сверки и выдачи результатов.
40 Rie
 
31.08.13
16:59
(38) Я тоже предпочитаю текстовые форматы - когда с ними я сам работаю. Но когда будет работать кто-то, тем более - бухгалтер и т.п.
41 DEVIce
 
31.08.13
17:01
(39) Ну блин тебе кучу вариантов набросали - сам решай.
42 bard666
 
31.08.13
17:06
(41) я так и сказал. Спасибо за советы и опыт сверок. Буду экспериментировать.
43 Serginio1
 
31.08.13
19:49
(38) Вместо текстовых файлов проще использовать XML через ФобрикXDTO. Например данные выгружаются по текущей фабрике.
Выгружается схема.И этой схеме загружаются в другую или наоборот. Можно создать свой пакет который использовать в обеих конфигурациях. Можно автоматически сгенерить v8: XSD схема программно с нуля.
44 Rie
 
31.08.13
20:04
(43) Не всегда это проще.
1С ведь совсем не зря поддерживает несколько различных способов интеграции.
45 Serginio1
 
31.08.13
20:18
(44)  Например? Через фабрику ты пишешь и читаешь обращаясь к объекту через точку. С текстом  нужно оперировать позицией в строке. Для простых случаев проще использовать ДБФ. В тексте нужно экранировать разделители строк. Итд. С XML проще, но его минус излишний размер, который больше влияет на передачу. Хотя   с моей точки зрения проще использовать специально заточенную для сериализации БД. Но это уже отклонения, в которых нет не только в 1С.
46 Rie
 
31.08.13
20:24
(45) Ну вот зачем мне фабрика XDTO, если я прекрасно могу без неё обойтись?
И зачем мне с текстом оперировать позицией в строке?
DBF - тоже замечательно. Но если у меня простая фиксированная структура, которую я читаю/пишу строго последовательно, то зачем DBF (который, к тому же, не всегда удобно смотреть)?

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

Хотя, конечно, воробья и из пушки пристрелить можно.
47 Rie
 
31.08.13
20:29
48 Serginio1
 
31.08.13
21:54
Дбф  как раз для фиксированных структур, текст обычно нужен для неструктурированной информации. А самым подходящим будет тот, на который нужно затратить минимум усилий, если конечно не стоит задача по скорости передачи данных.
Кстати есть еще и http://en.wikipedia.org/wiki/Protocol_Buffers

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

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

Для сериализации предпочтиетльне такая организация . Каждый тип хранится в своей таблице. Поля имеющие составнын типы хранятся в виде структуры тип (номер таблицы) и номер записи в таблице. Ссылки на известный тип просто запись в таблице, для значений переменной длины в блоб таблицах. Единственно, что нужно организовывать в памяти ввиде Хэш таблиц слежение за добавленными объектами. Это использование памяти.
49 Rie
 
01.09.13
06:16
"А самым подходящим будет тот, на который нужно затратить минимум усилий, если конечно не стоит задача по скорости передачи данных" - вот именно.
Тогда почему Вы столь упорно настаиваете, что нет задач, при которых такой самой подходящей структурой является plain text?
Ведь не всё же ваяется на века. Бывают и задачи, когда нужно быстро сделать сейчас и закрыть тему.
XDTO - замечательная штука. Но... Надо как минимум описать структуру пакета (кстати, где она описывается? не в конфигурации ли? ой, а у меня там сейчас пользователи работают...). А

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

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

ВывестиПоле(Текст,Закавычить(СтрокаТЧ.Номенклатура.УникальныйИдентификатор()));
ВывестиПоле(Текст,Закавычить(СтрокаТЧ.Номенклатура.Наименование));
ВывестиПоле(Текст,Строка(СтрокаТЧ.Остаток));
50 Rie
 
01.09.13
06:24
+(49) То же самое относится и в DBF (который иногда ничем не лучше CSV). Можно и в JSON сериализовать вместо XML - очень удобный формат. И т.д. и т.п.
Я ведь не отрицаю, что все эти технологии полезны. Более того - сам ими с удовольствием пользуюсь.
Мне лишь непонятна столь резкая неприязнь к plain text.
А ещё я с удовольствием хожу пешком - на небольших расстояниях это удобнее, чем автомобиль.
51 АйЭм
 
01.09.13
07:26
(19) Садись, два.
Пока сидишь - подумай, почему в OLE можно открыть форму приложения, а в COM низзя. )))))))))))))
52 DEVIce
 
01.09.13
08:39
(51) Садись кол. Я написал, что OLE - это частная реализация COM и не более того. :)
53 Serginio1
 
01.09.13
13:15
(50) Та я как раз пользуюсь всеми форматами. По поводу описания пакета, то его можно описать хоть где и не только в текущей конфигурации и необязательно в 1С. Есть схема XDTO которую можно создать и программно v8: XSD схема программно с нуля.

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

Говоря проще, не означает универсально. При том, что данный подход в этой ветке не проходил. А чем пользоваться в итоге каждый выбирает сам. В CSV роблемы с разделителями строк, которые нужно экранировать. в ДБФ поля имеют одинаковую длину. Но с ним плохо работать например со строками которые могут иметь длину от единицы до мегабайтов. Все зависит от ситуации. А загрузкой выгрузкой текстов я занимаюсь очень давно вплоть до генерации загрузок выгрузок как в текстовом и прочих форматов. Но начинающим проще все же начинать с ФабрикаXDTO. А там из приведенного тобой примера не хватает чтения и здесь Объекты XDTO выглядят лучше. Ну это уже на вкус и цвет.
54 Rie
 
01.09.13
13:17
(53) Экранировать символ - это проблема?
55 Serginio1
 
02.09.13
10:58
(54) Нет не проблема. Но это дополнительные движения и об этом нужно помнить работая с текстом. И соответственно при чтении нужно об этом помнить.
Либо поступать как при бинарной сериализации указывая длину строки, но это уже получается не текстовый файл с которым 1С не умеет работать.
Еще раз пусть каждый выбирает, что ему лучше. В большинстве случаев проще использовать ФабрикаXDTO.
56 bard666
 
16.09.13
16:48
Спасибо, обработину своял.
плюсы:
можно запустить и заняться другими задачами, потом проанализировать и исправить ошибки.
минусы:
порой быстрее самому через ексель сравнить.
57 zladenuw
 
16.09.13
17:00
(0) запуск фонового задание. которое вернет результат в другую базу или все ок или фиаско
Независимо от того, куда вы едете — это в гору и против ветра!