Читая анонсы обновлений 1С, задумывались, какая это замечательная возможность? Хотите использовать в своих решениях? В статье изложен опыт практического использования внешних источников данных, возможно, это "совсем не то, чего мы все так хотели".
Старый вариант через ADO не требует изменения конфигурации, но вот интересна скорость получения данных.
По сравнению с перебором в RecordSet и по сравнению с загрузкой с помощью компоненты GameWithFire.
(3) cool.vlad4, А в том то и штука что ADO не используется и даже OLEDB не используется. 1C взяли ниже уровень... наверное как раз чтобы под *nix работало... но как работает unixodbc это уже другой вопрос....
(5) Мы и не говорили, что используется, просто всех интересует сравнение скорости, но на самом деле лучше и проще, чтобы каждый для своей задачи проверил и сделал выбор.(ODBC там используется, если про то речь)
(7) cool.vlad4, на самом деле лучше если бы 1С "до ума" это довели и не заставляли нас мучаться... был бы во франче написал бы им прямо в суппорт. Вообще не дело ни с временными таблицами ни с другими данными соединять нельзя... прямо такое чувство что не доделали то что хотели...
(5) Вы просто подумали, что 3 я адресовал вам, нет он был адресован K_A_O, где я совственно и подчеркнул, чем Внешние источники лучше ADO и компоненты(и я не заметил, это в статье есть?)
(2) K_A_O, С учетом того что для работы через ADO в запросе сперва нужно выгрузить данные в таблицу значений, а потом во временную таблицу работает конечно быстрее... вот только гибкости при этом такой нет...
Я пробовал делать внешнее соединение, если сервер стоит на linux, но так и не довёл до конца (нет времени). Только путем проб и ошибок, можно понять как с этим работать, т.к. в 1с нет примеров как правильно написать строку подключения к Базе, использую unixodbc.
Пару месяцев назад уже столкнулся с внешними данными. Задача стояла в УТ3(11) получать данные из SQL по артикулу продукта. Сначала хотел быстренько кинуть внешние данные в запрос печати, да не тут то было... пришлось дописать клиентсерверные модули чтобы хоть как-то облегчить код в модулях документов.
Не так давно в дистрибутиве 1С появилась конфигурация Фабрика отчетов (Report factory) рекомендую всем стащить с неё модуль инициализации :)
Да попробовал я эту вещь и тоже нифига не понял, а зачем оно надо? видимо разработчики позаботились о том, <sarcasm> что всех очень мучило - чтение прайс листов на сервере</sarcasm> Надеюсь они доведут идею до логического конца....
Имхо лучше бы 1С тупо стырила из 1С++ код ODBCDataBase и ODBCRecordset.
Вот это бы было дело. А так - фигня какая-то получилась.
Это надо же придумать - описывать состав ВНЕШНЕГО источника данных в конфигурации.
А на лету подключится к произвольному источнику данных (для чего в свое время MS и создавала ODBC) - низзя.
(17) orefkov, Так "на лету" если нужно - подключайтесь через ADO без проблем... Как я понял весь смысл как раз в описании источника в конфигурации - чтобы можно было в конструкторе запросов использовать, и разименовывать как нравится... этакий аналог LinQ :)
(23) ничего, абсолютно ничего. Linq - это вывод типов (которого в 1С в принципе нет, да и не нужен по большому счету), это лямбда-выражения(грубо говоря анонимные функции), которых тоже нет, и самое главное в совокупности это работа практически с любой коллекцией (главное чтоб был интерфейс IQueryable), что позволяет работать как с AD, как с Ms SQL, как с xml и даже с Facebook, (потому как сама технология расширяема) и ей по барабану какой провайдер. Я честно слово перечитал статью еще раз и вообще не увидел ничего похожего на Linq. Даже на Linq to Sql.
PS Я помню кто-то сравнивал Linq и язык запросов от 1С, что якобы 1С придумала это раньше. Но ничего подобного. Linq коренным образом отличается и от языка запросов 1С, как по сути, так и по форме.
(29) cool.vlad4, По сути Linq язык описания структуры данных для удобства работы с ней из программного кода. Внешние источники данных нужны для той же цели. Вот с этой точки зрения посмотрите... создавались они для одного и того же. Просто подходы у 1с и microsoft очень разные :)
(30) Да сейчас работет через ADODB.Connection и ADODB.Recordset, но приходиться писать большие объемы данных и все это не очень быстро. Хочется чтоб работало быстрее.
А какие параметры указывать в полях AppName и Рабочая станция при работе с конструктором строки подключения? При всех вариантах: имя базы и пустота во всех сочетаниях, ответ один: "Возможно, заполнены не все параметры или их значение не допустимо". Если без конструктора, а в поле строки указываю стандартное скулевое: DRIVER={SQL Server};SERVER=[имя сервера];UID=[логин];PWD=[пароль];APP=вот здесь забил [upp] и прокатило;DATABASE=[имя базы SQL].
Насколько я понимаю плюсы в следующем:
1. Все запросы к внешним данным выполняются на сервере (в случае клиент-серверной архитектуры), что избавляет от настройки клиентских машин (у нас они измеряются сотнями);
2. Возможность использования конструктора для написания запроса к внешнему источнику данных;
3. Если есть различные источники данных с одинаковой структурой и несколько баз 1С (например в филиалах), то можно не меняя кода 1С просто подключить каждую базу 1С к своему источнику данных в тонком клиенте.
4. Возможность использования результата в СКД, что дает возможность построить отчет не написав не строчки кода, используя различные консоли, которые генерируют отчеты на СКД.
(44) Elgrego,
1) а вот если у вас на 1-ом локальном компьютере стоит какой-нибудь InterBase или ещё что-то доисторическое... нужно драйвер его поставить на сервер... а сервер 64 разрядный... вообщем для кого "+" а для кого "-". "-" ИХМО будет чаще
2) Собственно конструктором можно и так пользоваться... ТЗ, её во временную таблицу и пожалуйста
3) А вот нет... у Вас же всё на сервере работает :). А если источники данных - файлы Access, а сервер работает под учеткой с ограниченными правами :).
4) не могу не согласится... да, теоретически возможно написать отчет не написав ни строчки кода... пожалуй единственный "+". Но учитывая (1) (2) и (3) едва ли чего-то мы им достигнем...
Статья хорошая. Может вы уже разобрались во всех новшествах работы с этим чудо объектом конфигурации.
У меня такой вопросик, извиняюсь что пишу тут но очень очень нужна помощь.
При переходе с 14 на 15 платформу выходит ощибка.
"ВнешнийИсточникДанных.OKTELL.Таблица.dbo_A_Stat_Connections_1x1.Поле.Id: Тип поля ключа таблицы с объектными данными может быть только одним из примитивных типов."
Что делать???
Если меняешь тип на строку. Нарушается работа отчетов связанных с этим внешним источником данных.
Сделайте источником данных запрос, а в запросе как-нить CONVERT если у вас там тип приводится к примитивному... ну а если вы ключем хотите сделать не примитивный тип... ну.. ну вы понимаете :)
(0) Попробовал использовать базу Oracle как "ВнешнийИсточникДанных" полгода назад - получил такие эффекты , что со страхом откатился на на обычное ADO-соединение. А ты не пробовал ?
Уж не знаю где спрашивать, попытаю счастья тут :)
Хочу отойти от подключения по COM и использования UUID = COMОбъект.NewObject("УникальныйИдентификатор",Уник);
Сразу же захотелось попытаться подключить SQL базу 1С в качестве внешнего источников данных и "искать" в ней по GUID данные с целью сравнения на соответствие.
Ну и почти сразу же столкнулся с тем, что в SQL-табличке поле _IDRRef - бинарное. В строковой его транслировать его конечно можно, например CAST , потом "Переставить" в привычный для 1C порядок - но это все можно сделать на "далекой" SQL стороне, чего делать не хотелось бы. Отсюда вопрос, как можно заставить конструкцию
(53) kembrik, Это баян уже. Вам к извращенцам на SQL.ru - там уже давно "рецепт придуман", к примеру такой:
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=895717&msg=13053424... Но мой вам совет "не вступать на эту извилистую дорожку". SQL имеет смысл когда вы переносите регулярно тонны данных, но тогда надо юзать MS IS и отбор GUID в GUID, в вашем случае лучше правда COM или специализированные средства (WS или .Net компоненты).
(54), comol, да понятно что есть проверенные механизмы - но казалось бы, удобно то как могло бы быть. БД - вот они, рядышком, на одном и том же SQL сервере, только руку протяни, да поменяй строку подключения в зависимости от префикса ИБ. "Нашим" хочется отчеты строить шустренько, собирая номенклатуру из одного места, а "цену" из другого, и тому подобное. Придется, видимо, добавлять собаке пятую ногу
(55) kembrik, Если отчеты надо шустренько то вам прямой дорогой в сторону DWH. Оно как раз для этого и делается. Когда номенклатура в одном месте, а цена в другом это Best Practice обычно - MDM решения называется :). Далее OLAP. Ну или QlickView...
Появилась необходимость получить информацию из внешнего источника данных (SQL 2008).
Источник добавлен, и вроде бы всё хорошо, НО!
Некоторые таблицы содержат в себе колонку с именем "Index" (int), при упоминании этой колонки в запросе он перестает работать, а без неё никак, она ключевая.
- увы, но автор обманул читателей.
Открываем доку на ИТС, например для 8.3.10 и читаем
Для получения доступа к внешним источникам данных используется механизм ODBC. Данные внешних источников данных доступны как для чтения, так и для записи