Внешние источники данных в 1С 8.2.14.533
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Старый вариант через ADO не требует изменения конфигурации, но вот интересна скорость получения данных.
По сравнению с перебором в RecordSet и по сравнению с загрузкой с помощью компоненты GameWithFire.
По сравнению с перебором в RecordSet и по сравнению с загрузкой с помощью компоненты GameWithFire.
(7) cool.vlad4, на самом деле лучше если бы 1С "до ума" это довели и не заставляли нас мучаться... был бы во франче написал бы им прямо в суппорт. Вообще не дело ни с временными таблицами ни с другими данными соединять нельзя... прямо такое чувство что не доделали то что хотели...
Я пробовал делать внешнее соединение, если сервер стоит на linux, но так и не довёл до конца (нет времени). Только путем проб и ошибок, можно понять как с этим работать, т.к. в 1с нет примеров как правильно написать строку подключения к Базе, использую unixodbc.
Пару месяцев назад уже столкнулся с внешними данными. Задача стояла в УТ3(11) получать данные из SQL по артикулу продукта. Сначала хотел быстренько кинуть внешние данные в запрос печати, да не тут то было... пришлось дописать клиентсерверные модули чтобы хоть как-то облегчить код в модулях документов.
Не так давно в дистрибутиве 1С появилась конфигурация Фабрика отчетов (Report factory) рекомендую всем стащить с неё модуль инициализации :)
Не так давно в дистрибутиве 1С появилась конфигурация Фабрика отчетов (Report factory) рекомендую всем стащить с неё модуль инициализации :)
Да попробовал я эту вещь и тоже нифига не понял, а зачем оно надо? видимо разработчики позаботились о том, <sarcasm> что всех очень мучило - чтение прайс листов на сервере</sarcasm> Надеюсь они доведут идею до логического конца....
Имхо лучше бы 1С тупо стырила из 1С++ код ODBCDataBase и ODBCRecordset.
Вот это бы было дело. А так - фигня какая-то получилась.
Это надо же придумать - описывать состав ВНЕШНЕГО источника данных в конфигурации.
А на лету подключится к произвольному источнику данных (для чего в свое время MS и создавала ODBC) - низзя.
Вот это бы было дело. А так - фигня какая-то получилась.
Это надо же придумать - описывать состав ВНЕШНЕГО источника данных в конфигурации.
А на лету подключится к произвольному источнику данных (для чего в свое время MS и создавала ODBC) - низзя.
(23) ничего, абсолютно ничего. Linq - это вывод типов (которого в 1С в принципе нет, да и не нужен по большому счету), это лямбда-выражения(грубо говоря анонимные функции), которых тоже нет, и самое главное в совокупности это работа практически с любой коллекцией (главное чтоб был интерфейс IQueryable), что позволяет работать как с AD, как с Ms SQL, как с xml и даже с Facebook, (потому как сама технология расширяема) и ей по барабану какой провайдер. Я честно слово перечитал статью еще раз и вообще не увидел ничего похожего на Linq. Даже на Linq to Sql.
PS Я помню кто-то сравнивал Linq и язык запросов от 1С, что якобы 1С придумала это раньше. Но ничего подобного. Linq коренным образом отличается и от языка запросов 1С, как по сути, так и по форме.
PS Я помню кто-то сравнивал Linq и язык запросов от 1С, что якобы 1С придумала это раньше. Но ничего подобного. Linq коренным образом отличается и от языка запросов 1С, как по сути, так и по форме.
(29) cool.vlad4, По сути Linq язык описания структуры данных для удобства работы с ней из программного кода. Внешние источники данных нужны для той же цели. Вот с этой точки зрения посмотрите... создавались они для одного и того же. Просто подходы у 1с и microsoft очень разные :)
А какие параметры указывать в полях AppName и Рабочая станция при работе с конструктором строки подключения? При всех вариантах: имя базы и пустота во всех сочетаниях, ответ один: "Возможно, заполнены не все параметры или их значение не допустимо". Если без конструктора, а в поле строки указываю стандартное скулевое: DRIVER={SQL Server};SERVER=[имя сервера];UID=[логин];PWD=[пароль];APP=вот здесь забил [upp] и прокатило;DATABASE=[имя базы SQL].
Насколько я понимаю плюсы в следующем:
1. Все запросы к внешним данным выполняются на сервере (в случае клиент-серверной архитектуры), что избавляет от настройки клиентских машин (у нас они измеряются сотнями);
2. Возможность использования конструктора для написания запроса к внешнему источнику данных;
3. Если есть различные источники данных с одинаковой структурой и несколько баз 1С (например в филиалах), то можно не меняя кода 1С просто подключить каждую базу 1С к своему источнику данных в тонком клиенте.
4. Возможность использования результата в СКД, что дает возможность построить отчет не написав не строчки кода, используя различные консоли, которые генерируют отчеты на СКД.
1. Все запросы к внешним данным выполняются на сервере (в случае клиент-серверной архитектуры), что избавляет от настройки клиентских машин (у нас они измеряются сотнями);
2. Возможность использования конструктора для написания запроса к внешнему источнику данных;
3. Если есть различные источники данных с одинаковой структурой и несколько баз 1С (например в филиалах), то можно не меняя кода 1С просто подключить каждую базу 1С к своему источнику данных в тонком клиенте.
4. Возможность использования результата в СКД, что дает возможность построить отчет не написав не строчки кода, используя различные консоли, которые генерируют отчеты на СКД.
(44) Elgrego,
1) а вот если у вас на 1-ом локальном компьютере стоит какой-нибудь InterBase или ещё что-то доисторическое... нужно драйвер его поставить на сервер... а сервер 64 разрядный... вообщем для кого "+" а для кого "-". "-" ИХМО будет чаще
2) Собственно конструктором можно и так пользоваться... ТЗ, её во временную таблицу и пожалуйста
3) А вот нет... у Вас же всё на сервере работает :). А если источники данных - файлы Access, а сервер работает под учеткой с ограниченными правами :).
4) не могу не согласится... да, теоретически возможно написать отчет не написав ни строчки кода... пожалуй единственный "+". Но учитывая (1) (2) и (3) едва ли чего-то мы им достигнем...
1) а вот если у вас на 1-ом локальном компьютере стоит какой-нибудь InterBase или ещё что-то доисторическое... нужно драйвер его поставить на сервер... а сервер 64 разрядный... вообщем для кого "+" а для кого "-". "-" ИХМО будет чаще
2) Собственно конструктором можно и так пользоваться... ТЗ, её во временную таблицу и пожалуйста
3) А вот нет... у Вас же всё на сервере работает :). А если источники данных - файлы Access, а сервер работает под учеткой с ограниченными правами :).
4) не могу не согласится... да, теоретически возможно написать отчет не написав ни строчки кода... пожалуй единственный "+". Но учитывая (1) (2) и (3) едва ли чего-то мы им достигнем...
Статья хорошая. Может вы уже разобрались во всех новшествах работы с этим чудо объектом конфигурации.
У меня такой вопросик, извиняюсь что пишу тут но очень очень нужна помощь.
При переходе с 14 на 15 платформу выходит ощибка.
"ВнешнийИсточникДанных.OKTELL.Таблица.dbo_A_Stat_Connections_1x1.Поле.Id: Тип поля ключа таблицы с объектными данными может быть только одним из примитивных типов."
Что делать???
Если меняешь тип на строку. Нарушается работа отчетов связанных с этим внешним источником данных.
У меня такой вопросик, извиняюсь что пишу тут но очень очень нужна помощь.
При переходе с 14 на 15 платформу выходит ощибка.
"ВнешнийИсточникДанных.OKTELL.Таблица.dbo_A_Stat_Connections_1x1.Поле.Id: Тип поля ключа таблицы с объектными данными может быть только одним из примитивных типов."
Что делать???
Если меняешь тип на строку. Нарушается работа отчетов связанных с этим внешним источником данных.
Уж не знаю где спрашивать, попытаю счастья тут :)
Хочу отойти от подключения по COM и использования UUID = COMОбъект.NewObject("УникальныйИдентификатор",Уник);
Сразу же захотелось попытаться подключить SQL базу 1С в качестве внешнего источников данных и "искать" в ней по GUID данные с целью сравнения на соответствие.
Ну и почти сразу же столкнулся с тем, что в SQL-табличке поле _IDRRef - бинарное. В строковой его транслировать его конечно можно, например CAST , потом "Переставить" в привычный для 1C порядок - но это все можно сделать на "далекой" SQL стороне, чего делать не хотелось бы. Отсюда вопрос, как можно заставить конструкцию
работать ((
Хочу отойти от подключения по COM и использования UUID = COMОбъект.NewObject("УникальныйИдентификатор",Уник);
Сразу же захотелось попытаться подключить SQL базу 1С в качестве внешнего источников данных и "искать" в ней по GUID данные с целью сравнения на соответствие.
Ну и почти сразу же столкнулся с тем, что в SQL-табличке поле _IDRRef - бинарное. В строковой его транслировать его конечно можно, например CAST , потом "Переставить" в привычный для 1C порядок - но это все можно сделать на "далекой" SQL стороне, чего делать не хотелось бы. Отсюда вопрос, как можно заставить конструкцию
ТекГУИД=Строка(ТекСсылка.УникальныйИдентификатор());
"ВЫБРАТЬ
| dbo__Reference57._IDRRef,
| dbo__Reference57._Code,
| dbo__Reference57._Description,
| dbo__Reference57.Представление
|ИЗ
| ВнешнийИсточникДанных.Buh_utt.Таблица.dbo__Reference57 КАК dbo__Reference57
|ГДЕ
| dbo__Reference57._IDRRef = &ТекГУИД";
//
Показатьработать ((
(53) kembrik, Это баян уже. Вам к извращенцам на SQL.ru - там уже давно "рецепт придуман", к примеру такой:
. Но мой вам совет "не вступать на эту извилистую дорожку". SQL имеет смысл когда вы переносите регулярно тонны данных, но тогда надо юзать MS IS и отбор GUID в GUID, в вашем случае лучше правда COM или специализированные средства (WS или .Net компоненты).
. Но мой вам совет "не вступать на эту извилистую дорожку". SQL имеет смысл когда вы переносите регулярно тонны данных, но тогда надо юзать MS IS и отбор GUID в GUID, в вашем случае лучше правда COM или специализированные средства (WS или .Net компоненты).
(54), comol, да понятно что есть проверенные механизмы - но казалось бы, удобно то как могло бы быть. БД - вот они, рядышком, на одном и том же SQL сервере, только руку протяни, да поменяй строку подключения в зависимости от префикса ИБ. "Нашим" хочется отчеты строить шустренько, собирая номенклатуру из одного места, а "цену" из другого, и тому подобное. Придется, видимо, добавлять собаке пятую ногу
Появилась необходимость получить информацию из внешнего источника данных (SQL 2008).
Источник добавлен, и вроде бы всё хорошо, НО!
Некоторые таблицы содержат в себе колонку с именем "Index" (int), при упоминании этой колонки в запросе он перестает работать, а без неё никак, она ключевая.
Платформа 8.2.19.90.
Есть у кого варианты как это можно исправить?
Источник добавлен, и вроде бы всё хорошо, НО!
Некоторые таблицы содержат в себе колонку с именем "Index" (int), при упоминании этой колонки в запросе он перестает работать, а без неё никак, она ключевая.
Платформа 8.2.19.90.
Есть у кого варианты как это можно исправить?
Прикрепленные файлы:
Как я понял, INDEX это служебное имя, для корректного использования в SQL его заключают в квадратные скобки, но в 1С этот номер не проходит =( .
Попробовал получить через представление - все равно не получается.
Попробовал получить через представление - все равно не получается.
Прикрепленные файлы:
1. Создать в таблице новую колонку с новым именем (я выбрал INDEX_GUID)
2. В спецификации вычисляемого столбца указать ([index])
Таким образом мы получаем копию колонки INDEX, но с читаемым именем.
3. Обращаемся к колонке INDEX_GUID через источник данных - всё работает!
2. В спецификации вычисляемого столбца указать ([index])
Таким образом мы получаем копию колонки INDEX, но с читаемым именем.
3. Обращаемся к колонке INDEX_GUID через источник данных - всё работает!
Прикрепленные файлы:
платформа 8.3.8.2088
при подключении к 1с77 для полей "Строка(Х), Х>100" выдает сообщение
ВнешнийИсточникДанных Поле XXX: Для строки фиксированной длины запрещено задавать длину строки более 100 символов
Что делать ?
при подключении к 1с77 для полей "Строка(Х), Х>100" выдает сообщение
ВнешнийИсточникДанных Поле XXX: Для строки фиксированной длины запрещено задавать длину строки более 100 символов
Что делать ?
Прикрепленные файлы:
