Внешняя компонента для работы с базами данных SQLite, плюс прямые запросы в ДБФ-базах 1С.
Внешняя компонента, предназначенная для работы с базами данный SQLite.
Версия 1.0.2.3
Основана на проекте http://www.sqlite.org.
Основная страница проекта: http://snegopat.ru/1sqlite/
Кроме того, при работе в ДБФ-версии 1С, компонента позволяет посредством «движка» SQLite и встроенным в него механизмом «виртуальных таблиц» обращаться на чтение к таблицам базы данных 1С через «родные» методы самой 1С. Что позволяет выполнять запросы к базе 1С даже в монопольном режиме работы.
Основные фичи компоненты:
- SQLite версии 3.6.11
- Движок SQLite доработан в плане регистронезависимости русских символов, нормально работают lower, upper, like, названия таблиц, полей.
- Добавлено collate _1С — сравнение строк без учета регистра и завершающих пробелов.
- Отображение ДБФ-таблиц 1С в базу данных SQLite и возможность использовать их в запросах.
- Работа с ДБФ-таблицами 1С в монопольном режиме.
- Получение в прямых запросах «длинных» строк 1С-ДБФ.
- Типизация результатов запроса типами данных 1С.
- Работа с текстовыми и sql-параметрами в запросах.
- Укладка в базу данных SQLite ТаблицЗначений.
- Укладка в базу данных SQLite СписовЗначений с объектами 1С, с возможностью в ДБФ версии разворота групп справочников или счетов по иерархии.
- Поставщик данных табличного поля 1С++
История версий:
1.0.1.1
- Исправлен вылет при попытке подключить таблицу строк документа, у которого нет ТЧ.
- Добавлены текстовые параметры: :ВидСубконто и :ПланСчетов
1.0.1.2
- Исправлена работа с преобразованием значений типа Дата в формат БД.
1.0.1.3
- Исправлена ошибка в метапарсере при обработке вхождений текстовых параметров.
1.0.1.4
- Добавлено авто-подключение таблиц.
1.0.1.5
- Исправлена ошибка подстановки текстового параметра «:ВидСправочника.ХХХ»
- Добавлен модификатор 3 для подстановки значений типа Строка. Подставляет фрагмент текста без кавычек, для динамического формирования текста запроса.
1.0.1.6
- Исправлена подстановка значения пустой даты.
- Добавлена типизация :Субконто
- Добавлена типизация :Время
- Добавлена функция str2id
- Добавлена функция id2str
1.0.1.7
- Доработана работа 3го модификатора текстового параметра типа «Строка». Теперь подставляемый фрагмент текста также обрабатывается метапарсером.
- Удалены типизация «:ВидДокумента» и «:ВидДокументаПредставление».
- Добавлены типизации «:ИмяВида» и «:ПредставлениеВида».
- Доработан метод SQLiteQuery::ВыполнитьЗапрос. Теперь можно получать результат выполнения запроса в таблицу значений, список значений, полем из скалярного запроса, а также в любой объект, реализующий интерфейс загрузки результата запроса (ISQLiteResultLoader).
1.0.1.8
- Исправлена ошибка обработки NULL значений.
- Исправлена ошибка преобразования из utf-8 нулевых строк
- Устранена гигантская утечка памяти при некоторых случаях использования LIMIT
- Рефакторинг классов базы данных и запросов, с целью облегчения использования их в других компонентах
- Из соображений производительности восстановлены типизации :ВидДокумента и :ВидДокументаПредставление
- Из соображений производительности добавлены типизации :ВидСубконто и :ВидСубконтоПредставление
1.0.1.9
- — Сделано принудительное округление чисел при типизации :Число, тк получатели результата (кроме ТаблицыЗначений) сами этого не делают.
- Исправлена работа типизации при обработке NULL значений, тк получатели результата (кроме ТаблицыЗначений) сами этого не делают.
- Изменена логика работы с Begin/EndReadSequnce. В немонопольном режиме падение производительности, зато не падает.
- Добавлен метод SQLiteQuery::ОбработатьТекстЗапроса
- Добавлено свойство SQLiteQuery::ВыполнятьВТранзакции
- Исправлена ошибка программы при подключении таблиц шапки документа, не имеющего реквизитов шапки.
- Исправлена ошибка при выборке из таблиц 1С, иногда могущая привести к зависанию программы.
- Добавлено подключение таблиц ЖурналовРасчетов ДБФ версии 1С.
- Исправлена укладка списка объектов при наличии иерархии — неверно укладывались объекты, содержащие в идентификаторе русские буквы (распределенка с русским префиксом ИБ).
- Добавлен объект SQLiteDataProvider — поставщик данных табличного поля 1С++ для таблиц sqlite и таблиц 1С DBF-версии.
1.0.2.0 bugfix 2
- SQLite обновлен до релиза 3.6.11
- Добавлена способность ПоставщикаДанных динамически менять текст запроса, если некоторые поля не нужны табличному полю для отображения
- Добавлена возможность быстрого поиска для поставщика данных
- Исправлена ошибка выборки данных при некоторых условиях (where date <= ’09или19или29.месяц.год’ order by date desc)
- Убрана странная ошибка при попытке подготовить запросы с текстом запроса длиннее 972 символов.
- Порядок сортировки в ‘collate _1C’ сделан точно соответствующим порядку сортировки в дбф-файлах 1С.
- Изменены методы:
- SQLiteDataProvider::УстановитьТекстЗапроса
- SQLiteDataProvider::Отладка
- Добавлены методы:
- SQLiteDataProvider::НеУдалятьПоля
- SQLiteDataProvider::ПоляБыстрогоПоиска
- SQLiteDataProvider::ПолучитьТекстЗапроса
1.0.2.2
- SQLite обновлен до релиза 3.6.18
1.0.2.3
- SQLite обновлен до релиза 3.6.22
- Исправлена ошибка автоподключения таблиц 1С, названия которых начинаются с подчеркивания
- Доработано автоподключение таблиц 1С, теперь можно просто указывать имя таблицы, заключенное в [].
- Изменен алгоритм выгрузки результата запроса в СписокЗначений.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Не знал что Google Gears на нем основан ..
Поюзал. Прелестно! Если б с этой штукой консоль запросов (как в 8.0) замутить,то цены ей не будет.
Вот это — однозначно зачет! Даж сама идея скрестить SQLLite и 1C уже на «+» тянет.
Еще ветка для обсуждения на форуме прямых запросов для 1С —
Еще пример от Саши Орефкова
>>
В качестве примера — моя обработка — универсальное дерево подчиненности документов для ДБФ-версии.
>>1С++ не требуется, только 1sqlite.
Круть! Просто круть!
Народ, расскажите, что планируете сделать с помощью данной компоненты ?
Учебник в зубы: , замер производительности и вперёд! 😉
Ну вот… И что теперь с 1с++ делать? Только начинаю въезжать и использовать прямые запросы…
Однозначно! +!
А можно ли этим чудом потянуть данные из постороннего дбф (не из базы)?
В обработке «поисктовара» не прошли попытки типа :
запрос.ВыполнитьЗапрос(«create virtual table Товары1 using dbeng(Dt1628)») ;
текст=»SELECT * FROM Товары1″ ; //(c путями к файлу игрался)
(9)
DBF-ки отображаются только из родной базы.
ой, чувствую супершедевр какой-то… только начинаю прямые запросы читать (скуль для чайников активно изучаю) — а тут еще… что делать-то? что юзать для DBF-ины? 1С++ или эту?
Завел проект на googlecode
Исходники качать любым svn-клиентом.
(11)
Ну, если нужно работать в дбф монопольно, то другого пути нет.
А изучать 1С++ — завсегда пригодится.
(11)
Вообще-то, строго говоря — изучать надо структуру базы 1С и язык SQL.
А 1С++ и 1sqlite — просто инструменты для доступа к базе.
1С++ для работы с данной DLL — не требуется?
(15)
Напиши алгоритм для выяснения фонетической похожести. Движок SQLite позволяет и свои функции на С++ подключать.
Встроим ее в компоненту, будешь писать where ПохожеНа(descr, ‘вася’) > 1
(16)
1sqlite самодостаточная компонента, скрипач не нужен.
(17) спсб за оперативные ответы!!!
по (15) я — не умею.. *-(
выборку справочника товаров на 2500 позиций делает мгновенно…
(19)
2500 — для моряка это пыль 🙂
Мини-консоль для запуска запроса. Можно примерчик для консоли?
(21)
Ну, нажимаешь «Подключаемые таблицы», ставишь галку на Справочник.Номенклатура, потом пишешь в окошке
select id [Товар :Справочник.Номенклатура]
from Справочник_Номенклатура
where descr between ‘Б’ and ‘Г’
Жмешь F5.
Видишь все товары, чьи наименования начинаются на Б, В. Если есть товар с названием «Г», его тоже увидишь.
(19)(Сhe Burashka)
“выборку справочника … делает мгновенно…”
Если в запросе не используется индекс – естественно. Это к вопросу (5) из . Выборка обычный циклом без индекса будет работать также быстро.
Интересная разработка. В части подцепить внешнюю СУБД и дать удобный интерфейс к ней – отлично. А в части прямых запросов к DBFной базе данных 1Са, для данной СУБД – очередной самообман. Достаточно иметь средство отключения индекса при просмотре таблицы и скорость выборки, для некоторых задач, значительно повысится. При этом можно будет пользоваться стандартными языковыми средствами 1Са обработки данных. Конечно для полноценной (эффективной) обработки данных полезно иметь возможность искать и позиционироваться на запись по ключу (чего нет в стандартном языке 1Са), но это реализуется гораздо проще и в использовании проще, чем написание никчемных запросов.
Хотя это дело вкуса 🙂
(24)
Буду очень благодарен, если ты покажешь мне, на каких типичных задачах в 1С помогла бы выборка в физическом порядке записей.
Тупая выборка из таблица без упорядочивания мало кому интересна.
А «никчемные» запросы рвут язык 1С как тузик грелку, хоть на родном движке dbeng32, хоть на прилепленном тобой движке.
Дико извиняюсь, но твою подмену движка 1С я рассматриваю как попытку поставить более мощный движок на машину с квадратными колесами (язык 1С).
Как не форсируй движок, только грохота от колес больше, а толку не много.
А эта разработка — попытка к боле-менее нормальному движку (dbeng32) приделать круглые колеса, на каких во всем мире принято ездить.
(26)+
Да, совсем забыл сказать. В (19) Сергей (Сhe Burashka) отметил высокую скорость выборки в Вашей разработке. Думаю, он пробовал “поисктовара.ert”. Я в (23) написал “Если…”. Вношу исправления в своё сообщение. Никаких “если”. Именно так и есть. Таблица просматривается в физической последовательности. Это и есть основная причина быстрого выполнения выборки информации. И запрос (как инструмент) не имеет к повышению скорости никакого отношения.
(26)
Вообще, ты приводишь много утверждений, мало относящихся к действительности.
Для начала — движок 1С не может просматривать таблицу в порядке индекса.
Делаем запрос — select rowid, descr from Справочник_Номенклатура
Видим — опана — результат выдается в порядке физических записей, безо всяких индексов, хотя я использую родные методы dbeng32.dll
Далее — ты говоришь, что выборка в порядке индекса чудовищно проигрывает выборке в порядке физических записей.
Проверяем: 1ый Запрос, выборка без индекса.
select rowid from Справочник_Номенклатура
Выполнено: строк 16961, время 37 мс.
2ой запрос, выборка по индексу IDD
select rowid from Справочник_Номенклатура order by id
Выполнено: строк 16961, время 38 мс.
3й запрос, выборка по индексу PDESCR
select rowid from Справочник_Номенклатура order by descr
Выполнено: строк 16961, время 58 мс.
Вывод — при выборке в порядке индкеса скорость уменьшается в зависимости от длины ключа.
При коротких ключах (ID — 9 символов, DESCR — 100 символов) скорость практически не изменяется.
Но даже и на длинном ключе индекса, чудовищных провалов нет.
Ну и наконец приведенный тобой пример задачи
«Например, отчет по остаткам для всех товаров с сортировкой по реквизиту, не имеющему индекса.»
Осторожнее, не вводи в заблуждение неискушенных пользователей.
Основная нагрузка здесь — получение остатков по товару из регистра, при чем здесь перебор справочника в физическом порядке?
Попробуй сделать это, просматривая еще и файлы регистров в порядке физических записей.
То есть гипотетический расклад расхода времени примерно таков:
Перебор справочника товаров — 5%
Для каждого товара вычисление остатка — 80%
Сортировка результата: 15%
Пусть вместо перебора справочника по индексу используется перебор в порядке физических записей.
Какой выигрыш мы в итоге получим?
Зависит от того, по какому индексу ходит сама 1С.
Если по IDD, то как было показано выше — разницы практически нет.
Если по PDESCR, то да, выборка пройдет в 1.5 — 2 раза быстрее. Однако учитывая, что в общем времени рассчета отчета этот этап занимал 5%, то в целом ускорение отчета составит ничтожную величину.
Можешь написать, как бы делал такой отчет с помощью твоих расширений языка 1С?
Очень бы было интересно посмотреть.
В дополнение к 28.
Вообще-то, приведенный тобой отчет делается вообще без перебора справочника товаров.
Ну и еще в дополнение к 28.
Построение отчета для ТиС.
Получение остатка товаров на ТА с упорядочиванием по реквизиту ВидНоменклатуры:
Процедура Сформировать() Попытка база = СоздатьОбъект("SQLiteBase"); Исключение ЗагрузитьВнешнююКомпоненту("1sqlite.dll"); база = СоздатьОбъект("SQLiteBase"); КонецПопытки; база.Открыть(":memory:"); запрос = база.НовыйЗапрос(); запрос.ВыполнитьЗапрос("create virtual table ОстаткиТМЦ using dbeng(РегистрИтоги.ОстаткиТМЦ)"); запрос.ВыполнитьЗапрос("create virtual table Номенклатура using dbeng(Справочник.Номенклатура)"); запрос.Подставлять("ДатаТА", НачМесяца(ПолучитьДатуТА())); //запрос.Отладка(); т1 = _GetPerformanceCounter(); тз = запрос.ВыполнитьЗапрос(" |select | Номенклатура.ВидНоменклатуры [ВидНоменклатуры :Перечисление.ВидыНоменклатуры], | Остатки.Номенклатура [Товар :Справочник.Номенклатура], | Остатки.Остаток [Остаток :Число.15.5] |from | (select | Номенклатура, | sum(Количество) Остаток | from ОстаткиТМЦ | where Period = :ДатаТА | group by Номенклатура) Остатки | left join Номенклатура on Остатки.Номенклатура = Номенклатура.id |order by Номенклатура.ВидНоменклатуры |"); т2 = _GetPerformanceCounter(); Сообщить("Время выполнения запроса: " + (т2 - т1) + " Строк получено: " + тз.КоличествоСтрок()); тз.ВыбратьСтроку(); КонецПроцедурыПоказать полностью
Решения с помощью твоего расширения языка 1С пока не вижу.
ПолуОФФ: Саш, а может ты телепат докрутишь так, чтоб было удобно писАть запросы для 1sqlite?
В дополнение к 30.
Сравнил со штатным запросом 1С.
Процедура Сформировать1С() Перем Запрос, ТекстЗапроса, Таб; //Создание объекта типа Запрос Запрос = СоздатьОбъект("Запрос"); ТекстЗапроса = "//{{ЗАПРОС(Сформировать1С) |Без итогов; |Товар = Регистр.ОстаткиТМЦ.Номенклатура; |Количество = Регистр.ОстаткиТМЦ.Количество; |Функция Остаток = КонОст(Количество); |Группировка Товар упорядочить по Товар.ВидНоменклатуры без групп; |"//}}ЗАПРОС ; т1 = _GetPerformanceCounter(); Запрос.Выполнить(ТекстЗапроса); т2 = _GetPerformanceCounter(); тз = СоздатьОбъект("ТаблицаЗначений"); Запрос.Выгрузить(тз, 2, 0); Сообщить("Время 1С:" + (т2 - т1) + " Строк: " + тз.КоличествоСтрок()); тз.ВыбратьСтроку(); КонецПроцедурыПоказать полностью
Даже на демке ТиСа, где остатки всего по 61 товару, получил при нескольких запусках:
Время 1С:269 Строк: 61
Время выполнения запроса: 2 Строк получено: 61
Время 1С:318 Строк: 61
Время выполнения запроса: 2 Строк получено: 61
Время 1С:425 Строк: 61
Время выполнения запроса: 2 Строк получено: 61
Время 1С:430 Строк: 61
Время выполнения запроса: 2 Строк получено: 61
прям битва титанов, Орефкова и Ходжика … 😉
читать это все жутко интересно… Просьба к мэтрам, по возможности, конструктивно обсуждать, а то вы чего-то злобствовать начали…
По мну, например данная разработка видимо будет стартовой площадкой к освоению прямых запросов на 1С++ — потренируюсь пока на DBFe — как-то оно чуть более понятно…
.. в качестве варианта предлагаю запрограммить парочку тяжелых отчетов для типовой тис, например, отчет о состоянии заявки…
тьфу, как-то все сумбурно…
восьмерка нервно курит в сторонке 🙂
(33) .. в качестве варианта предлагаю запрограммить парочку тяжелых отчетов для типовой тис, например, отчет о состоянии заявки…
Кому предлагаешь? Если сам хочешь вкурить, то сам и пробуй написать. 😉
(35) Хитрый, аднака! 😉
Тут панимаешь монстры пиписьками меряются 😉 — куда уж мне 😉
По хорошему, взять две типовые ТиСы, на одну сабж прикрутить, на вторую — движок Ходжика
и рассмотреть — +/-, удобства/неудобства и т.д. — весьма пользительный и интересный материал бы получился (имхо)
Бухитоги не видит компонента ?
(38) ну если ты возьмёшься переписать все трудные места на прямые запросы — флаг в руки. ИМХО, это очень кропотливая работа и никто просто так делать её не будет
(36,37) А что хитрого? Я ж тебе без иронии посоветовал. А по-другому никак: пока сам не сядишь, никакой чужой запрос тебе не поможет.
(41) Товарищ Че будет ждать подробной документации и всеобъемлющих примеров.
Хорошо еще, что не сказал, что стыдно выкладывать такую сырую поделку без должного документирования и что разработчики в очередной раз зажрались.
(33)
Ну, вот сляпал «Состояние заявки». Проверьте. Единственно, что период берется только от дкумента до ТА.
ВК для отчета нужно 1.0.1.4
Спасибо всем откликнувшимся!!!!!!! особенно товарищу Орефкову, чья… ну эта… принадлежность оказалась самой длинной 😉
Буду тестить и активно вкуривать…
ПОТОМУ ЧТО 8-КА МЕНЯ НЕ ПОРАДОВАЛА СВОИМ БЫСТРОДЕЙСТВИЕМ…
+(44)
Написал аналог программы из (30) на средствах прямого доступа из своей разработки. Это не самый лаконичный и эффективный способ решения данной задачи. Её можно решать, например, построением постоянного индекса, установкой фильтров на сторон
..мдя… это надо осмыслить…
(39)
В компоненте есть доступ к системным таблицам 1Sxxxx.
Так что вполне можно обратится к бухитогам.
Только пока не сделана типизация :Субконто.
Но доделаю в ближайшее время.
(46)
О, вот пошел конструктивный разговор. Отлично. Таки вот рассказываю, как выполняются запросы в SQLite.
Текст запроса парсится движком SQLite, и для выполнения запроса создается «мини-программа», некий байт-код,
который затем исполняется виртуальной машиной SQLite (VDBE — virtual database engine — часть движка SQLite)
Эту программу можно просмотреть — достаточно перед текстом запроса добавить слово «explain», и вместо выполнения запроса будет возвращена программа его выполнения.
Это преамбула была. А теперь амбула.
Если посмотреть программу выполнения того запроса, то можно увидеть, что алгоритмически она практически эквивалентна приведенному тобой алгоритму.
Но. Выполнения этой программы делается не интерпретатором 1С, а интерпретатором SQLite, который гораздо шустрее.
Кроме того, заточен он именно на выполнение типичных операций с данными, например, вместо примитивного поиска/вставки в ТЗ используется поиск/вставка в индексированной временной таблице и тп.
Вот такие плюсы вырисовываются — вместо ручного написания алгоритма на 1С, с медленным выполнением его интерпретатором 1С, более короткий и лаконичный запрос, который преобразуется практически в такой же алгоритм, но еще и выполняемый гораздо быстрее и эффективнее.
Народ, кто-нить пробовал проверить выложенный отчет «Состояние заявки» ?
Интересны результаты на нормальных базах, а то я только на демке ТиСа проверял.
Да, там если фильтр по товару ставить, немного лишних данных может вылазить, не обращайте внимания, я попозже поправлю.
(49) посмотрел отчет о состоянии на живой базе. У нас в регистр.резервыТМЦ добавлено измерение «партии», поэтому в строках документа и движениях номенклатура может повторяться.
В этом случае получаем Резерв = Выписано * КоличествоСтрокСДаннойНоменклатурой. (В общем-то случай частный…).
По скорости со штатным запросом сравнивать смысла нет — отрабатывает мгновенно.
Поясните, плиз, что значит » навигационные алгоритмы», «навигационный способ»…?
я догадываюсь, но хочется определенности…
что-то я потерялся… обсуждение чего идет..? Ходжик говорит, что то, что сделал Орефков — это типа «костыль» для инвалида — ходить будет, и даже возможно бегать сможет, но в соревнованиях — не выиграет… и в соревнованиях имеет смысл допускать инвалидов, которым вместо костылей приживили фоигенные сервомотрочики вместо ног…? типа правильно я понял?
бегло затестил обработку по отчету о состоянии заявки — переделал вывод в базовых единицах.. ну что сказать… штатная считала… эээээ… не хочится озвучивать… — взял заявку из ПРЕДЫДУЩЕГО МЕСЯЦА — считала штатная отчетина более полутора минут — мне ждать надоело — полез комменты читать — орефковская — отсчитала секунды за 3-4 (субъективно большую часть времени заняло обновление строки состояния)… В штатной все время занимает расчет остатков на дату заявки — идет долгая сборка данных…
в проверяемой заявке — 400 строк…
(52,53)(Сhe Burashka)
Навигационный способ, в части чтения:
1) Установить позицию на запись в таблице по ключу индекса или номеру записи.
2) Переместиться по таблице на N записей к началу или концу таблицы от текущей записи в порядке индекса или физическом порядке.
3) Установить позицию на начало или конец таблицы в порядке индекса или физическом порядке.
Моя основная мысль в данном осуждении, что утверждение Александра “запросы рвут язык 1С как тузик грелку” есть самообман. Я считаю, что в языке 1Са не хватает навигационных команд для написания полноценных и эффективных алгоритмов. И запрос к этому не имеет никакого отношения. Запрос в данной разработке лишь использует полный набор навигационных команд. Возможно не всегда оптимальным образом. Писать алгоритм в виде заброса или непосредственно навигационными командами – дело вкуса. Однако при написании алгоритма непосредственно навигационными командами можно всегда обеспечить максимальную эффективность.
Далее мы сползли на обсуждение моего “прилепленного” движка, т.к. в нем, кроме всего прочего, есть расширения стандартного языка 1Са в части прямого доступа к таблицам навигационными командами. Естественно, далее я стал говорить о “всем прочем” в моей разработке. И пытаюсь подвести собеседника к тому, что мной изготовленные “костыли” имеют большее значение, чем средства написания алгоритмов выборки. Т.е., что “содержание” важнее “формы”. Хотя и признаю, что “форма” в этой разработке сделана хорошо.
На вопрос “обсуждение чего идет..?” затрудняюсь ответить. Обмен текстами идет, но, по-моему, в разных темах. :-(((
+(56)(Сhe Burashka)
Кстати. Использование разработки 1SQLite не отменяет возможности использования моей разработки в части режима клиент/сервер. Единственно, что запросы будут выполняться на стороне клиента. Т.е. в чистом виде будут давать только
(54)
В типовой ТиС (по крайней мере в той версии, что у меня есть (9.2 7.70.947)) для этого отчета не совсем оптимален регистр Заявки и ЗаказыЗаявки.
Если в регистре Заявки у измерения ЗаявкаПокупателя включить «Отбор движений», в ЗаказыЗаявки у измерения ЗаявкаПокупателя поставить «Отбор итогов», и слегка переписать запрос, можно добится еще большей скорости выполнения отчета.
(57)
А вот это радует.
Если я правильно понял, можно использовать с 1С твой движок, и моя компонента все-равно будет работать?
(53)
Не по словам суди, а по делам.
Ты ведь пример отчета запускал. Костыль это или сервомоторчик?
К тому же можно взять, и запустить код из (30), (32), (46), замерить время.
Больше кому-то что-то доказывать я не собираюсь.
Молча делаю свою работу.
(59) Главное не останавливаться.
(58)
“можно использовать с 1С твой движок, и моя компонента все-равно будет работать?”
Никаких противоречий для этого нет. Ошибки, конечно, могут выскочить. Но их проявление, думаю, будет очевидным сразу. И мы с Вами их быстро исправим, каждый со своей стороны.
“Больше кому-то что-то доказывать я не собираюсь”
Действительно, думаю, доказывать не надо. Но обсуждать “теорию”, а не только “практику” – имеет смысл.
“Молча делаю свою работу”
Уважаемый Александр. Это зря, в смысле “молча”. Думаю, Вашу разработку совершенно реально “подвинуть в направлении” клиент/серверной технологии “рвущей как тузик грелку” SQLную версию “1С 7.7”. И не только в части участков, которые можно написать на прямых запросах, но и в целом. Но это решать только Вам. Надумаете – пишите, звоните…
2 Ходжик: спсб за разъяснения,
если есть возможность: поясните ценность «навигационного подхода» и его пользу при работе по поиску и выборкам данных по сложным условиям… как-то я слабо себе представляю ценность перемещения «навигационным подходом» по базе данных за исключением прямых выборок доков/справочников… или я чего-то не понимаю…?
в свое время писал небольшую СУБД, где все работало безо всяких ключей/индексов — привязка шла исключительно по физическим номерам записей — все просто летало… но процедура реструктуризации базы жмакала долго…
(62)(Сhe Burashka)
Сергей, и Вам спасибо за проявляемый интерес к данной теме.
Этот, на первый взгляд, простой и короткий, вопрос имеет длинный ответ. Правда, ответ то же простой и от этого излагать его сложно. У меня был случай, когда я целый месяц по 14 часов в сутки рассказывал “ЭТО” высококлассному программисту применительно к АСУпным задачам в части “SQL или не SQL”. Начинать надо с самого начала.
Чем отличаются (в части обработки данных) задачи АСУп от ИПС.
В ИПС требуется искать (выбирать) “вдоль и поперек”. Единственно (упрощаю изложение!), что можно сделать для ускорения обработки это построить индексы с простым индексным выражением. Тем самым уменьшить количество просматриваемых записей – установить по одному реквизиту позицию по ключу и далее двигаться по таблице, выполняя “лобовое” сравнение остальных реквизитов самой записи. Если говорить о наших задачах, то отчеты это ИПС.
В АСУп очень много алгоритмов выполняющихся регулярно по жесткому алгоритму. И для уменьшения количества просматриваемых записей вполне реально построить постоянные индексы со сложным индексным выражением. Приведу пример индекса для получения должников, при условии, что итоги хранятся в самом справочнике клиентов:
IIF(Отгружено>Оплачено,”-“,IIF(Отгружено<Оплачено,”+”,” “))+STR(ABS(Отгружено-Оплачено),15,2)
Т.е. для просмотра списка должников достаточно выполнить позиционирование по “-” и перемещаться в любом (!) направлении без предварительной выборки в массив. При этом количество просматриваемых записей будет равно количеству должников. Если говорить о наших задачах, то использование таких “индексов” это все остальные задачи кроме отчетов. Но можно использовать такие индексы и в отчетах с фиксированным алгоритмом основных критериев отбора.
Т.е. суть разницы между ИПС и АСУпом в части обработки данных это — где лежит само условие выборки – в алгоритме (условие запроса) или в данных (индексное выражение). При проектировании схемы базы данных необходимо учитывать это. Для универсальных систем, таких как “1C:Предприятие” это не простая задача. А если ориентироваться на движок, который не позволяет строить сложных индексных выражений, часто и вообще не решаемая задача. Что мы и видим в SQLной версии 1Са.
Вот такое начало моего ответа на Ваш вопрос. Дальше продолжать?
Ясен пень продолжать, если не в лом! 😉
интерес есть, потому как постоянно хочется «попрограммить» для души — но удается редко, потому как больше востребованы именно «1Сные» задачи (постанови и развития учета), более тонкие моменты (оптимизация, ускорение, увеличение эффективности) — это задачи не «первой необходимости», и, как правило , если такая задача у организации стоит — то, скорее всего, уже и есть решатель…
я таки правильно понял, что разыменовывание полей запроса при выполнении не поддерживается?
То есть такой запрос
//**********************************
SELECT
Ост.Товар [Товар :Справочник.Товары],
Ост.Товар.Артикул
FROM
РегистрИтоги_ОстаткиТоваров as Ост
//**********************************
не выполняется, выдавая ошибку: no such column Ост.Товар.Артикул.
А то было бы круто.
Хотя и так, круче некуда.
Спасибо большое!! 😀
(63)
Универсальную систему (типа 1С) на таких индексных выражениях не сделать. Приведенный тобой пример очень упрощен.
Хотел бы я посмотреть, как построить индексное выражение для поиска должников, если у одного клиента 6 отгрузок с разными датами и разными сроками кредита, 8 оплат разнесенных по разным договорам, да еще и накопительные бонусы какие-нить.
(65)
Нет, не делается. Это не восьмерка и не запросы семерки.
Показать полностью
2 hogik
Навигационный метод получения данных это конечно здорово и всё такое. Знать как это работает действительно необходимо, и без этого никогда не решишь задачу методами декларативными. Но вот вопрос: почему же тогда все стараются использовать декларативные методы вместо процедурных?
Мне в своё время пришлось много поработать с BTreeve, и восторга от этого я как-то не испытывал. На SQL я делаю то же самое, но быстрее, и с меньшими травмами мозга. Да, при этом я в любой момент могу досконально разобраться, во что раскрутится мой запрос, но в большинстве случаев это не требуется.
P.S. Это ни в коем случае не упрёк или наезд. Это просто реплика из зала. Личное мнение на основе личного опыта.
+68
Я бы уточнил — без этого никогда оптимальноне решишь задачу методами декларативными
эээ… да, слово пропустил 🙂
+(71)
Александр.
Возможно, то о чем я говорю проясниться, если Вы загляните в описание API для Advantage. И начнёте его смотреть вот с этого:
Skips the given number of records:
UNSIGNED32 AdsSkip (ADSHANDLE hO
Ура ! Бухитоги сделаны !!!
+(72)
В случае с Advantage стоит ещё вспомнить о её цене. 🙁
+(74)
И сравнить ее с ценой MS SQL 😉
2orefkov, Саша, а есть ли в планах на будущее добавление возможности работы с произвольной базой 1с дбф, типа OLEDBdata.ПрисоединитьИБ() в 1срр?
(76)
Не знаю. Я пока не смог подключить движок 1С к другой базе.
натолкните на путь истинный, как добраться до бухитогов… собственной головой дошел только до того что нужно создать запрос «create virtual table Проводки using dbeng(_1С.ENTRY)» 🙁
можно примерчик, как хотябы осв по счету сделать (например остатки по складу)… или как сделать аналог СКД(Счет,ТипСуммы,Валюта,Субконто)
вроде получается…. подключил в консоли таблицу Проводки, теперь работает запрос
select
Docid,
ktsc0,
accdtid
from Проводки
where DATE > 20080427 and DATE < 20080629 and accdtid = ‘ N’
где N — идентификатор счета10.1
я на правильном пути ?
Александр.
Я запустил пример из (30) со своей DBEng32 для Advantage.
Faulting application 1cv7.exe, version 7.70.0.25,
faulting module 1sqlite.dll, version 1.0.1.7,
fault address 0x0000225e.
Разбираться бум? Если – да. То как?
+(82)
Слетает сразу после первого вызова:
GetTable() для RG405
(68)(ADirks)
В дополнение к моему ответу в (71) для ADirks:
“…при этом я в любой момент могу досконально разобраться, во что раскрутится мой запрос…”
Занимаясь поиском ошибки из моего сообщения (82) я обнаружил, что количество операций чтений справочника “Номенклатура” в примерах (30) и (46) различается в два раза не в пользу запроса.
(95)
Можешь показать, как ты обнаружил разницу в количестве операций чтения справочника?
(98)
“Можешь показать, как ты обнаружил разницу в количестве операций чтения справочника?”
Ссылка:
Файл: DBEng32.doc.
Раздел: “Настройка”
Пункты про “Строка № 7” и “Строка № 8”.
Если нет времени заниматься установкой сервера БД (для сравнения) то можно:
1) Использовать версию для CodeBase 6.5 c режимом ПДБД.
2) Мне выслать Вам результат выполнения моего примера из (46).
Ну, а для не сравнения, а анализа установка сервера БД не требуется.
Но меня больше интересует Ваш ответ на (94). Не в смысле делать это сейчас, а в смысле обсудить. Возможно, и другие алгоритмы Вашей разработки упростятся. И это повлияют на написания того, что Вы делаете сейчас по основной теме разработки. Ну, а если не повлияет, то можно и отложить…
(106)
Ну, я примерно понял в чем дело.
При соединении со справочником по id движок запросов вынужден считывать запись, следующую за найденной, потому что нигде не указано, что индекс по id уникальный, то есть нет гарантий, что в таблице нет повторяющихся id. Я не считаю это большой проблемой. По крайней мере, в гипотетической ситуации задвоения айдишника в справочнике, запрос отработает фактически верно, в соответствии с реальными данными. Хотя можно и доработать компоненту, условно считать индексы по id справочников, iddoc в журнале и шапках документов уникальными.
(107)
“движок запросов вынужден считывать запись, следующую за найденной”
Ну, если еще и это делает, то в 4 раза больше чтений. Запустите трассировку. Там много еще другой полезной информации. Но ответ на вопрос из (106->94) хАчу…
(108)
Таки я не понял, в два или в четыре?
Ты в первый раз трассировку плохо посмотрел?
Был бы очень благодарен, если бы ты кинул мне на orefkov gmail.com трассировки для запроса и для подсчета твоим способом.
И замеры времени выполнения обоих способов.
Дико извиняюсь, но тебе сделать это проще, чем мне.
(109)
“Таки я не понял, в два или в четыре?”
Если рассматривать то место, которое я смотрел, когда говорил в два раз – то в два раза.
А если учесть то, что написано Вами в (107), то еще в два раза. Т.е. в результате – в четыре раза.
“И замеры времени выполнения обоих способов.”
Это шутка? Я уже писал, что у меня нет большой базы в типовой ТиС. А на демо-версии у меня всё выполняется одинаково – около 0 секунд. И отличия на уровне ошибки измерения.
“если бы ты кинул мне”
Кину в течение ближайшего часа.
“Дико извиняюсь, но тебе сделать это проще, чем мне.”
Нам надо не извинятся, а переходить на более оперативные средства общения. Уж больно много времени уходить на написание буковок.
(110)
Буду ждать.
А «отличия на уровне ошибки измерения» — ну так смотря чем и как мерять.
Если использовать _GetPerformanceCounter, который меряет с точностью до мсек, да прокрутить в цикле 10000 раз, то что-то все равно ведь выйдет?
(111)
“ну так смотря чем и как мерять”
Вот именно “как”.
“Если использовать _GetPerformanceCounter,”
,а не чем!
“в цикле 10000 раз, то что-то все равно ведь выйдет?”
Нет.
(112)
“Ну, для начала надо иметь список методов, которые подменяет твоя разработка”
Все.
“то бишь какими именно штатными методами и свойствами dbeng32 можно оперировать.”
Любыми.
Но для начала надо брать описание схемы базы данных не из управляющих блоков CodeBase-а.
Я, в своей, разработке беру эту информацию из 1CV7.DD. Это то, что я увидел при беглом (!) просмотре исходных текстов 1SQLite.
(113)
«Но для начала надо брать описание схемы базы данных не из управляющих блоков CodeBase-а.»
Можно объяснить подробнее, что имеется ввиду?
Из схемы базы данных я беру только состав полей и индексов для желаемой таблицы, черех объекты CTable, CIndex, CField.
Из наполнение будет отличаться при работе твоей версии dbeng32.dll ?
(114)
Александр.
Вы читали моё сообщение (94) по поводу ошибки в совместной работе наших разработок?
“Можно объяснить подробнее, что имеется ввиду?”
Вот это:
char* recordBuffer() const {return *(char**)((*(char**)((**(char***)(((char*)p_1C) + 0xC)) + 0x1C)) + 0x14) + 1;}
“…будет отличаться при работе твоей версии dbeng32.dll ?”
См. (113) ответ на (112). И если чего не заработает, то только из-за моей опечатки в программе. Но это быстро мной исправится.
(115)
Никак не вижу связи между «recordBuffer()» и 1CV7.DD.
Это просто получение адреса буфера, куда складываются данные записи после перемещения по таблице.
Если отказаться от этого, придется переписывать многое в части получения значений полей записи.
Либо как-то от твоего движка узнать адрес буфера с записью.
(115)
“Никак не вижу связи между «recordBuffer()» и 1CV7.DD”
Я ранее написал “при беглом (!) просмотре исходных текстов 1SQLite”. И если не требуется никакой другой информации из управляющих блока кроме адреса буфера ввод/вывода CoseBase, то и не надо использовать 1CV7.DD. А получать это штатным способом (CTable, CIndex, CField).
“Либо как-то от твоего движка узнать адрес буфера с записью”
При использовании моей разработки не используется буфер ввод/вывода родного CodeBase. И для того, чтобы не связываться с ним, надо использовать методы FX_… из CstoreObj. В родной DBEng32 содержание буфера, в общем случае, не предсказуемо. Т.е. они выполняют ввод/вывод средствами CodeBase в буфер и ничего не знают о его местоположении в памяти и сразу выполняют пересылку нужных полей из буфера в переменные 1Са методами FX_… до выполнения следующей операции ввода/вывода для этой же таблицы. А в методах FX_… используются функции CodeBase получения значения поля по его имени.
(21)>Время 1С выгрузкой итогов: 8
Во! Чисто интуитивно я никогда не заморачивался никакими запросами, а всегда делал выгрузку итогов по регистру.
Конечно, 2 секунды куда как круче, но и 8 нормалёк :)))
(особенно по сравнению с 325 и 30)
(121)
Александр.
Замечание по ходу обсуждения. Я не говорил “не удалось”. Моя мысль по это этому поводу была высказана примерно такая – “при сравнении в таких условиях, сравнивается не скорость работы движка, а скорость работы интерпретатора 1С”. Что полностью соответствует Вашим утверждениям в сообщении (48). И думаю, соответствует, одной из целей Вашей разработки. И если маленькие базы положить на RAM диск, то разница будет еще больше. Т.к. доля времени выполнения, той части, которую Вы оптимизируете — очень мала по сравнению со временем выполнения операций ввода/вывода.
Вы, с интервалом в два года, написали две фразы про грелку:
“запрос на 1С++ рвет дбф, как тузик грелку”
“запросы рвут язык 1С как тузик грелку”.
Я, как тогда, так и сейчас говорю, что слово “запрос” не имеет к этим утверждения никакого отношения. И слова “язык” и “dbf” тоже не имеют никакого отношения к “грелке”. Я попытался это изложить в (71) данной темы и пытался это сказать два года назад. Но, два года назад, я еще пытался ответить на вопрос “почему ж на самом деле тормозит 1С:Предприятие” при использовании в качестве написания движка для 1С языка запросов.
Что касается приведенного Вами сравнения, то наверно имеет смысл еще написать – при каких условиях проводилось данное сравнение. Т.е. по сети, в режиме клиент/сервер, какой использовался сервер БД и т.д. И не для меня, а для других людей, читающих комментарии к Вашей разработке. Лично мне эти результаты очевидны и без проведения тестирования.
Ну, а я подожду следующую Вашу фразу про грелку. Возможно, в ней появится истинный смысл того, кто кого и при каких условиях – “рвет как грелку”.
P.S. Жаль, что на разработку можно ставить только один плюс от одного плюсующего. Я б, от себя поставил гораздо больше.
я посмотрел да,там нет выборки по названию dbf,и он еще не открывается я какую то неправильную видно dll foxpro зарегистрировал ош фоксЗапрос.Выполнить(«EXECSCRIPT(‘SET ANSI OFF’)»);
{\TSCLIENTD\_ЗАПРОСОСТАТКИИОБОРОТЫ_ФОКС_СКУЛЬЛАЙТ.ERT(13)}: FAILED! ICommandText::Execute(): Variable ‘ ‘ is not found.
(273) поставить этот провайдер:
(если не стоит заплатка от hogik, выполнять запросы через этот провайдер можно только в НЕ монопольной базе)
(274) Ёпрст, я качал эту dll,она не устанавливается на виртуальной машине,говорит не могу установится через подключение к удаленному столу.