1sqlite
Разработка - Разработка внешних компонент
Бесплатные
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Узнавайте о новых бесплатных решениях в нашей телеграм-группе Инфостарт БЕСПЛАТНО
| Наименование | Скачано | Бесплатно |
|---|---|---|
|
1sqlite 1.0.2.3
.zip 408,69Kb
1424
|
1424 | Скачать бесплатно |
|
Пример использования (поиск клиентов/товаров в ДБФ базе 1С)
.1214222839 8,01Kb
1102
|
1102 | Скачать бесплатно |
|
Мини-консоль для запуска запроса.
.1214287828 7,33Kb
957
|
957 | Скачать бесплатно |
|
Пример использования. Универсальное дерево документов (для ДБФ)
.1214287870 7,44Kb
826
|
826 | Скачать бесплатно |
|
Документация к 1.0.2.3
.zip 62,42Kb
1047
|
1047 | Скачать бесплатно |
|
Пример использования. Отчет "Состояние заявки" для ТиС ДБФ. (работает только на дату ТА)
.1214393726 12,42Kb
716
|
716 | Скачать бесплатно |
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Внешняя компонента, предназначенная для работы с базами данный 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С, теперь можно просто указывать имя таблицы, заключенное в [].
- Изменен алгоритм выгрузки результата запроса в СписокЗначений.
Загрузчик данных из 1С в BI-системы
Решение «Экстрактор данных 1С в BI» автоматически выгружает данные из 1С 8.3 в ClickHouse, PostgreSQL, Microsoft SQL для интеграции с BI. Работает с типовыми и кастомными конфигурациями 1С. Доступна бесплатная 5-дневная демо-версия.
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Файловый обмен (TXT, XML, DBF), FTP Перенос данных 1C Разработчик 1С:Предприятие 7.7 1С:Предприятие 8 1С:Бухгалтерия 7.7 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)
Перенос данных из 1С:Бухгалтерия 7.7 в БП 3.0 | Продукт является развитием и исправлением ошибок стандартной обработки для выгрузки данных из 1С Бухгалтерии 7.7 в Бухгалтерию 3.0 | Перенос из 7.7 является сложным, и на рынке сложно найти специалистов 1С по "семерке" - сотрудники помогут вам выполнить переход в рамках техподдержки предлагаемого переноса данных!
58000 руб.
26.05.2020 39816 14 100
Файловый обмен (TXT, XML, DBF), FTP 1С:Предприятие 7.7 1C77 Россия Платные (руб)
Класс 1С++ для подключения ФИАС (Федеральная информационная адресная система) к любой конфигурации 1С 7.7. Опционально доступно геокодирование адресов и хранение географических координат адресных элементов ФИАС в отдельной БД. В конфигурации, где для ведения адресов используется типовой интерфейс по работе с КЛАДР, встраивается за пару минут.
6100 руб.
15.11.2017 28433 32 71
Разработка внешних компонент Системный администратор Разработчик 1С:Предприятие 7.7 1С:Предприятие 8 Россия Платные (руб)
Аддон "Структура Обмена" (ExchangeStruc) - это компонента, которая обеспечивает доступ к разделяемым процессом структурам, аналогичным структурам 1С. Обеспечивает прозрачную передачу данных примитивных типов, в том числе Двоичных данных, в режиме Реального времени между разными контекстами (формами) или потоками одного процесса. В перспективе функционал будет расширен для обмена между процессами, даже разных версий платформ. Совместим с версиями Windows рабочих станций и серверов, с платформами 1С разных версий и релизов в режиме Native начиная с 8.2, и в режиме COM начиная с версий 7.7. По скорости чтения и записи лишь немногим уступает стандартной структуре 1С. НОВОЕ: Добавлен функционал регистрации компоненты COM в качестве OLE Auto (COMОбъект) для поддержки её работы в серверах старых версий 1С: 8.0 и 8.1, где работа с компонентами исключена. Теперь можно коммуникацию с Фоновыми заданиями на этих версиях проводить.
7320 руб.
19.04.2023 7310 1 0
Файловый обмен (TXT, XML, DBF), FTP Учет документов Распознавание документов и образов Бухгалтер Пользователь 1С:Предприятие 7.7 1С:Предприятие 8 1C:Бухгалтерия 1C77 1С:Бухгалтерия 2.0 1С:Бухгалтерия 3.0 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 1.х 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 1.6 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Платные (руб)
Программный комплекс способный распознавать сотни листов за раз любых сканированных(фото) документов (УПД, ТОРГ12, СФ, паспорт и пр.) и загружать их в любую 1С (БП3.0, УТ, КА, УНФ, УПП, 1С7.7 ТиС, ЗУП3 и пр.), а также формировать архив сканированных документов.
Робот применяет до 5 способов распознавания. Максимальное качество загрузки документов из бесплатных OCR. Работает без Интернета.
10980 руб.
13.10.2022 11850 1 12
Разработка внешних компонент WEB-интеграция Разработчик 1С:Предприятие 7.7 1C77 Платные (руб)
Компонента HttpSrv7 позволяет создавать веб-сервисы в среде 1С 7.7 и, используя файлы HTML, несложные веб-сайты. С помощью нее можно обеспечить доступ к данным 1С 7.7 из браузера. Дополнительно используя компоненту HTTP_Async можно наладить обмен данными между удаленными информационными базами по протоколам HTTP, HTTPS и WebSocket. С помощью компоненты HttpSrv7 используя протокол WebSocket можно создавать и поддерживать работу нескольких чатов. С помощью компоненты HTTP_Async можно асинхронно отправлять HTTP-запросы к сайтам, веб-сервисам (в т.ч. к HTTPSrv7) и обрабатывать ответы по мере их поступления. Компонента GISMT в дополнение к HTTP_Async имеет функцию цифровой подписи в формате Base64 и, таким образом, имеет все возможности для работы с API ГИС МТ "Честный знак" непосредственно из среды 1С 7.7.
6100 руб.
27.05.2022 13621 2 20
Разработка внешних компонент Разработчик 1С:Предприятие 7.7 Платные (руб)
Компонента для выбора значения из больших списков значений.
5084 руб.
02.12.2021 8337 3 19
Файловый обмен (TXT, XML, DBF), FTP Перенос данных 1C Разработчик 1С:Предприятие 8 Оперативный учет 7.7 1С:Торговля и склад 7.7 1С:Бухгалтерия 3.0 Бухгалтерский учет Управленческий учет Абонемент ($m)
Обработка и правила обмена данными для выгрузки документов и всех связанных с ними справочников из 1С7.7 ТиС 9.2 в 1С8.3 БП 3.0 через файл XML. В типовых конфигурациях уже есть такое решение. Это немного доработанные правила и сама обработка выгрузки, добавлена возможность устанавливать отбор по выгружаемым документам по Фирме, Контрагенту, Складу, Проекту, Автору, ЮрЛицу. А также это внешняя обработка, что даёт возможность адаптировать её под нетиповую ТиС. Обработка и правила тестировались на платформах: 1С: Предприятие 7.7 и 1С: Предприятие 8.3.18.1334. На типовых конфигурациях: «Торговля + склад», редакция 9.2 (7.70 1004) и «Бухгалтерия предприятия» редакция 3.0 (3.0.96.30).
1 стартмани
13.08.2021 13249 100 Kuzya_brаtsk 8
Внешние источники данных Разработчик 1С:Предприятие 7.7 1C77 Украина Абонемент ($m)
Рабочий механизм чтения/записи строк в формате JSON для 1С 7.7. Тестировалось на релизах 7.70.25 и 27.
1 стартмани
16.12.2019 27136 76 Volvo32 33
Однозначно! +!
А можно ли этим чудом потянуть данные из постороннего дбф (не из базы)?
В обработке "поисктовара" не прошли попытки типа :
запрос.ВыполнитьЗапрос("create virtual table Товары1 using dbeng(Dt1628)") ;
текст="SELECT * FROM Товары1" ; //(c путями к файлу игрался)
{\\TSCLIENT\D\_ЗАПРОСОСТАТКИИОБОРОТЫ_ФОКС_СКУЛЬЛАЙТ.ERT(13)}: FAILED! ICommandText::Execute(): Variable ' ' is not found.
а вот если бы в поиске клиентов работала фонетическая похожесть....???
по (15) я - не умею.. *-(
Ну, нажимаешь "Подключаемые таблицы", ставишь галку на Справочник.Номенклатура, потом пишешь в окошке
select id [Товар :Справочник.Номенклатура]
from Справочник_Номенклатура
where descr between 'Б' and 'Г'
Жмешь F5.
Видишь все товары, чьи наименования начинаются на Б, В. Если есть товар с названием "Г", его тоже увидишь.
Во! Чисто интуитивно я никогда не заморачивался никакими запросами, а всегда делал выгрузку итогов по регистру.
Конечно, 2 секунды куда как круче, но и 8 нормалёк :)))
(особенно по сравнению с 325 и 30)
Хотя это дело вкуса :-)
Буду очень благодарен, если ты покажешь мне, на каких типичных задачах в 1С помогла бы выборка в физическом порядке записей.
Тупая выборка из таблица без упорядочивания мало кому интересна.
А "никчемные" запросы рвут язык 1С как тузик грелку, хоть на родном движке dbeng32, хоть на прилепленном тобой движке.
Дико извиняюсь, но твою подмену движка 1С я рассматриваю как попытку поставить более мощный движок на машину с квадратными колесами (язык 1С).
Как не форсируй движок, только грохота от колес больше, а толку не много.
А эта разработка - попытка к боле-менее нормальному движку (dbeng32) приделать круглые колеса, на каких во всем мире принято ездить.
По пунктам:
1) “ты покажешь мне, на каких типичных задачах” – У меня в (24) написано “некоторых”. Например, отчет по остаткам для всех товаров с сортировкой по реквизиту, не имеющему индекса. Результат записывается в рабочий файл (массив) и потом сортируется по данному реквизиту. Но в 1С справочник всегда просматривается с учетом индекса, в данном случае, не имеющем никакого отношения к поставленной задаче. Другой пример, это когда надо выполнить задачу из Вашего примера “поисктовара.ert”. Ведь в Вашем примере результат поиска заносится в таблицу значений и перед её отображением можно выполнить сортировку по любому реквизиту. И т.д.
2) “Тупая выборка из таблица без упорядочивания мало кому интересна” – В любом отчёте, где не удаётся уменьшить количество релевантных записей путем применения индекса, требуется именно такая “Тупая выборка”.
3) “запросы рвут язык 1С как тузик грелку” – В случае клиент серверной технологии уменьшают нагрузку на сеть, используют кэширование на сервере, использую более производительную подсистему ввод/вывода сервера и т.д. А в Вашей разработке прямые запросы только расширяют возможности языка 1Са доступа к данным. Но расширить возможности языка в этой части можно и другим способом. Причем здесь (в этой Вашей фразе) запросы?
4) “хоть на родном движке dbeng32” – А Вашей разработке используется другой движок?
5) “хоть на прилепленном тобой движке” – Мой движок “прилеплен” с другой целью. И без изменения конфигурации обеспечивает производительность выше, чем в SQLной версии 1Са. При сопоставимой надежности. И гораздо меньшими затратами на железо, программное обеспечение, доработку системы и т.д. А в части повышения скорости работы 1Са с изменением конфигурации в моей разработке описаны средства расширения стандартного языка 1Са. Описание этих средств укладывается на одной странице формата А4. И по количеству строчек, добавляемых в конфигурацию меньше, чем аналогичное решение задачи с применением запросов SQL. При этом написать алгоритм выборки данных можно более эффективный с меньшими затратами мозгов.
6) “ Дико извиняюсь, но твою подмену движка 1С я рассматриваю…” – Оставлю без комментариев.
7) “только грохота от колес больше, а толку не много” – Работает с базой в 6 гигабайт (только DBFов), одновременно 50-75 человек. Круглосуточно, розница, 50000 наименований товаров, несколько сот тысяч видов работ в производстве. Днем, в часы пик, документы ложатся в базу каждые пять секунд. Стоимость сервера (компьютера) 1200 долларов (три года назад).
8) “А эта разработка - попытка к боле-менее нормальному движку (dbeng32) приделать круглые колеса” – Так мы говорим о движке или о приделках к нему “круглых колес”? Т.е. о форме или содержании? У меня сложилось впечатление, что Вы к плохому движку приделали бантики. И ожидаете, что в целом это будет работать лучше. Т.е. сделали косметический ремонт.
9) “на каких во всем мире принято ездить” – Если Вы имеете в виду язык SQL, то на нем “ездят” многие. Только “управляют” этой “машиной” люди с головой.
Да, совсем забыл сказать. В (19) Сергей (Сhe Burashka) отметил высокую скорость выборки в Вашей разработке. Думаю, он пробовал “поисктовара.ert”. Я в (23) написал “Если…”. Вношу исправления в своё сообщение. Никаких “если”. Именно так и есть. Таблица просматривается в физической последовательности. Это и есть основная причина быстрого выполнения выборки информации. И запрос (как инструмент) не имеет к повышению скорости никакого отношения.
Вообще, ты приводишь много утверждений, мало относящихся к действительности.
Для начала - движок 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С?
Очень бы было интересно посмотреть.
1) “много утверждений, мало относящихся к действительности” - Полностью с Вами согласен. Надеюсь, что дальнейшее наше обсуждение это прояснит. И мы начнем говорить об одной и той же “действительности”. Пока мы говорим о разных вещах. А если говорить о действительности, то было бы интересно узнать информацию аналогичную той, что я привел в пункте номер 7 сообщения (26) только с применением Вашей разработки.
2) “движок 1С не может просматривать таблицу в порядке индекса” – Возможно, Вы забыли поставить “не” перед “порядке индекса”. Я эту фразу буду обсуждать с учетом “не”. Я этого не говорил. Мало того, в своей разработке даю возможность просматривать таблицы в физической последовательности в рамках интерфейса движка. Но наличие этой возможности в движке и его интерфейсе не говорит о том, что в стандартном языке и алгоритмах 1Са это используется.
3) “ты говоришь, что выборка в порядке индекса чудовищно проигрывает выборке в порядке физических записей” – И этого я не говорил. Я говорил, что проигрывает. А чудовищно или не чудовищно зависит от масс других факторов. Я говорил, что, то ускорение, которое наблюдал Сергей, связано с просмотром таблицы в физической последовательности. Но не только от этого.
4) “при выборке в порядке индкеса скорость уменьшается в зависимости от длины ключа” – И от этого тоже.
5) “Ну и наконец приведенный тобой пример задачи… не вводи в заблуждение неискушенных пользователей” – Никакого ввода в заблуждение я не делаю. Я привожу пример просмотра всей таблицы и только. Второй, мой, пример на базе “поисктовара.ert” должен прояснить пользователю суть моего первого примера.
6) “Основная нагрузка здесь - получение остатков по товару из регистра, при чем здесь перебор справочника в физическом порядке?” – А причем здесь остатки.
7) “Попробуй сделать это, просматривая еще и файлы регистров в порядке физических записей” – У нас нет никаких регистров. Но суть фразы меня настораживает. Я ни в одном своём сообщении в этой теме не предлагал заменять просмотр по индексу на просмотр в физической последовательности.
8) “расклад расхода времени примерно таков” – Это у Вас такой расклад. У нас получение остатков делается одной командой найти по ключу. Но это совсем другая тема. Будет у Вас желание – обсудим. А по сути самих цифр Вашего примера смотрите ответ в пункте номер 5 данного сообщения.
9) “Можешь написать, как бы делал такой отчет с помощью твоих расширений языка 1С?” – Для сравнения скорости - точно такой отчет написать не могу. Т.к. в типовой ТиС у меня нет большой базы, а в нашей базе нет никаких регистров. И соответственно нет такого соотношения, приведенных, Вами цифр. При этом этот пример не имеет никакого отношения к теме нашего обсуждения. Мы обсуждаем - смотрите пункт номер 3 данного сообщения. И я утверждаю, что никакого отношения к этому факту запрос не имеет. Что касается примеров из моей разработки к обсуждаемой теме – они есть в подкаталоге EXT.
10) “приведенный тобой отчет делается вообще без перебора справочника товаров” – Я не приводил пример отчетов. Я приводил пример полного просмотра таблицы. Зачем, же так конкретно этот пример воспринимать?
11) “Построение отчета для ТиС … Решения с помощью твоего расширения языка 1С пока не вижу” – Попробую написать. Только не так быстро. Я с 2000 года не имею никакого отношения к таким понятиям как регистры, ТА и т.д. Забыл уже многое.
12) “Сравнил со штатным запросом 1С” – И не буду. Т.к. это совсем не в нашей теме. Сравнивать скорость выполнения штатных запросов имеет смысл в DBFной, SQLной версиях 1Са и в моей разработке. И желательно в реальных условиях – по сети.
Написал аналог программы из (30) на средствах прямого доступа из своей разработки. Это не самый лаконичный и эффективный способ решения данной задачи. Её можно решать, например, построением постоянного индекса, установкой фильтров на стороне сервера и т.д. Т.е. я хотел представить самый очевидный способ решения задачи для начала конструктивного разговора на эту тему.
| Код |
|---|
Процедура Выполнить()
Перем Тов,Рег,Инд,Зап,Таб,Дат,ИдТ,Поз,Пус;
ЗагрузитьВнешнююКомпоненту("AddInExt.dll");
Ext=СоздатьОбъект("AddIn.AddInExt");
Тов=СоздатьОбъект("Справочник.Номенклатура");
Пус=ЗначениеВСтрокуВнутр(ПолучитьПустоеЗначение("Справочник.Номенклатура"));
Рег="РегистрОстаткиТМЦ";
Инд="PROP";
Дат=Формат(НачМесяца(ПолучитьДатуТА()),"ДГГГГММДД");
Таб=СоздатьОбъект("ТаблицаЗначений");
Таб.НоваяКолонка("ИдТов","Строка");
Таб.НоваяКолонка("Код","Строка");
Таб.НоваяКолонка("Наименование","Строка");
Таб.НоваяКолонка("ВидТов","Строка");
Таб.НоваяКолонка("Количество","Число");
Зап=Ext._(41,Рег,Инд,Дат);
Пока Число(Зап)>0 Цикл
Если Ext._(43,Рег,"PERIOD")<>Дат Тогда Прервать; КонецЕсли;
ИдТ=Ext._(43,Рег,"Номенклатура");
Поз=0;
Если Таб.НайтиЗначение(ИдТ,Поз,"ИдТов")=0 Тогда
Тов=ЗначениеИзСтрокиВнутр(Ext._(22,Ext._(43,Рег,"Номенклатура"),Пус));
Таб.НоваяСтрока();
Таб.ИдТов=ИдТ;
Таб.Код=Тов.Код;
Таб.Наименование=ВРег(СокрЛП(Тов.Наименование));
Таб.ВидТов=Тов.ВидНоменклатуры;
Таб.Количество=0;
КонецЕсли;
Таб.Количество=Таб.Количество+Число(Ext._(43,Рег,"Количество"));
Зап=Ext._(42,Рег,Инд,Зап,1);
КонецЦикла;
Таб.Сортировать("ВидТов");
Таб.ВыбратьСтроку();
Таб.Сортировать("Код");
Таб.ВыбратьСтроку();
Таб.Сортировать("Наименование");
Таб.ВыбратьСтроку();
КонецПроцедуры
Показать полностью |
Построение отчета для ТиС.
Получение остатка товаров на ТА с упорядочиванием по реквизиту ВидНоменклатуры:
| Код |
|---|
Процедура Сформировать()
Попытка
база = СоздатьОбъект("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С пока не вижу.
Я запустил пример из (30) со своей DBEng32 для Advantage.
Faulting application 1cv7.exe, version 7.70.0.25,
faulting module 1sqlite.dll, version 1.0.1.7,
fault address 0x0000225e.
Разбираться бум? Если – да. То как?
Итак.
1sqlite vs AddIn.AddInExt
Сравнивались времена получения сводного остатка на ТА ресурса Количество из регистра ОстаткиТМЦ демо-базы ТиСа, по измерению Номенклатура, без итогов и групп, упорядоченные по ВидНоменклатуры,Номенклатура четырмя способами:
1. Запросом 1С.
2. Выгрузкой итогов из регистра в ТЗ с последующим добавлением и заполнением колонки ВидНоменклатуры и сортировкой ТЗ по этой колонке.
3. Запросом 1sqlite
4. Навигационным способом из (46) с применением AddIn.AddInExt
Результатом выполнения каждого из способов являлась ТЗ, содержащая как минимум колонки
- Номенклатура (тип Справочник.Номенклатура)
- ВидНоменклатуры (тип Перечисление.ВидыНоменклатуры)
- Количество
упорядоченная по колонкам ВидНоменклатуры, Номенклатура.
Заставить заработать AddIn.AddInExt и 1sqlite в одной базе у меня не получилось - AddIn.AddInExt не работал в базе с "родным" dbeng32.dll, 1sqlite соответственно, не работал в базе данных на CodeBase'ом dbeng32.dll от hogik'а.
Поэтому были созданы две базы данных с одинаковыми данными, в каждой из которых были прогнаны по 3 способа:
В базе с родным dbeng32.dll - способы 1, 2, 3
В базе с движком hogik'а - способы 1, 2, 4
Время выполнения тестов 1 и 2 в каждой базе дадут основания косвенно сравнить меж собой и способы 3 и 4.
Каждый из способов прогонялся подряд 5 раз. После каждого теста в окно сообщений выводилось время выполнения в мсек и количество строк в полученной ТЗ.
Замеры времени выполнялись через _GetPerformanceCounter.
Результаты замеров
База с родным dbeng32.dll:
Время 1С запросом: 325 Строк: 61
Время 1С запросом: 385 Строк: 61
Время 1С запросом: 389 Строк: 61
Время 1С запросом: 403 Строк: 61
Время 1С запросом: 452 Строк: 61
Время 1С выгрузкой итогов: 8 Строк: 61
Время 1С выгрузкой итогов: 8 Строк: 61
Время 1С выгрузкой итогов: 8 Строк: 61
Время 1С выгрузкой итогов: 9 Строк: 61
Время 1С выгрузкой итогов: 9 Строк: 61
Время 1sqlite: 2 Строк: 61
Время 1sqlite: 2 Строк: 61
Время 1sqlite: 2 Строк: 61
Время 1sqlite: 2 Строк: 61
Время 1sqlite: 3 Строк: 61
База с движком от hogik:
Время 1С запросом: 367 Строк: 61
Время 1С запросом: 410 Строк: 61
Время 1С запросом: 411 Строк: 61
Время 1С запросом: 390 Строк: 61
Время 1С запросом: 380 Строк: 61
Время 1С выгрузкой итогов: 13 Строк: 61
Время 1С выгрузкой итогов: 13 Строк: 61
Время 1С выгрузкой итогов: 13 Строк: 61
Время 1С выгрузкой итогов: 13 Строк: 61
Время 1С выгрузкой итогов: 13 Строк: 61
Время hogik: 30 Строк: 61
Время hogik: 29 Строк: 61
Время hogik: 29 Строк: 61
Время hogik: 30 Строк: 61
Время hogik: 30 Строк: 61
Если кто желает воспроизвести тесты, могу выслать обработку для их проведения.
Александр.
Замечание по ходу обсуждения. Я не говорил “не удалось”. Моя мысль по это этому поводу была высказана примерно такая – “при сравнении в таких условиях, сравнивается не скорость работы движка, а скорость работы интерпретатора 1С”. Что полностью соответствует Вашим утверждениям в сообщении (48). И думаю, соответствует, одной из целей Вашей разработки. И если маленькие базы положить на RAM диск, то разница будет еще больше. Т.к. доля времени выполнения, той части, которую Вы оптимизируете - очень мала по сравнению со временем выполнения операций ввода/вывода.
Вы, с интервалом в два года, написали две фразы про грелку:
“запрос на 1С++ рвет дбф, как тузик грелку”
“запросы рвут язык 1С как тузик грелку”.
Я, как тогда, так и сейчас говорю, что слово “запрос” не имеет к этим утверждения никакого отношения. И слова “язык” и “dbf” тоже не имеют никакого отношения к “грелке”. Я попытался это изложить в (71) данной темы и пытался это сказать два года назад. Но, два года назад, я еще пытался ответить на вопрос “почему ж на самом деле тормозит 1С:Предприятие” при использовании в качестве написания движка для 1С языка запросов.
Что касается приведенного Вами сравнения, то наверно имеет смысл еще написать – при каких условиях проводилось данное сравнение. Т.е. по сети, в режиме клиент/сервер, какой использовался сервер БД и т.д. И не для меня, а для других людей, читающих комментарии к Вашей разработке. Лично мне эти результаты очевидны и без проведения тестирования.
Ну, а я подожду следующую Вашу фразу про грелку. Возможно, в ней появится истинный смысл того, кто кого и при каких условиях – “рвет как грелку”.
P.S. Жаль, что на разработку можно ставить только один плюс от одного плюсующего. Я б, от себя поставил гораздо больше.
Сравнил со штатным запросом 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 - как-то оно чуть более понятно...
.. в качестве варианта предлагаю запрограммить парочку тяжелых отчетов для типовой тис, например, отчет о состоянии заявки...
тьфу, как-то все сумбурно...
Кому предлагаешь? Если сам хочешь вкурить, то сам и пробуй написать. ;)
По хорошему, взять две типовые ТиСы, на одну сабж прикрутить, на вторую - движок Ходжика
и рассмотреть - +/-, удобства/неудобства и т.д. - весьма пользительный и интересный материал бы получился (имхо)
В компоненте есть доступ к системным таблицам 1Sxxxx.
Так что вполне можно обратится к бухитогам.
Только пока не сделана типизация :Субконто.
Но доделаю в ближайшее время.
(46)
О, вот пошел конструктивный разговор. Отлично. Таки вот рассказываю, как выполняются запросы в SQLite.
Текст запроса парсится движком SQLite, и для выполнения запроса создается "мини-программа", некий байт-код,
который затем исполняется виртуальной машиной SQLite (VDBE - virtual database engine - часть движка SQLite)
Эту программу можно просмотреть - достаточно перед текстом запроса добавить слово "explain", и вместо выполнения запроса будет возвращена программа его выполнения.
Это преамбула была. А теперь амбула.
Если посмотреть программу выполнения того запроса, то можно увидеть, что алгоритмически она практически эквивалентна приведенному тобой алгоритму.
Но. Выполнения этой программы делается не интерпретатором 1С, а интерпретатором SQLite, который гораздо шустрее.
Кроме того, заточен он именно на выполнение типичных операций с данными, например, вместо примитивного поиска/вставки в ТЗ используется поиск/вставка в индексированной временной таблице и тп.
Вот такие плюсы вырисовываются - вместо ручного написания алгоритма на 1С, с медленным выполнением его интерпретатором 1С, более короткий и лаконичный запрос, который преобразуется практически в такой же алгоритм, но еще и выполняемый гораздо быстрее и эффективнее.
1) ” Таки вот рассказываю, как выполняются запросы в SQLite” – Уважаемый Александр. Пожалуйста, не отвлекайтесь на такие мелочи. Я в курсе того, как выполняется запрос в SQLite и как Вы “подцепились” к ней в своей разработке.
2) “Выполнения этой программы делается не интерпретатором 1С, а интерпретатором SQLite, который гораздо шустрее” – Давайте, откажемся от двойных стандартов. Вы очень конкретно привели мне цифры, по моему примеру “отчета” по остаткам – какую долю времени занимает просмотр таблицы в физической или по индексу последовательности по отношению к взятию остатков. Так сделаете это и в случае сравнения Вашей разработки с предложенным мной способом расширения штатного языка 1Са. И если Вы призываете к “конкретному разговору” то давайте конкретно – “цифры в студию”. А потом сопоставьте их со скорость работы самого движка – стандартного 1Совского и моего “прилепленного” движка. Далее вспомните о надежности клиент/серверного решения, о снятом ограничении на размер таблицы, об устранении клинчей и проблемы 100% занятости процессора, о возможности выполнения примитивных запросов и фильтров на стороне клиента, о возможности построения постоянного индекса и т.д.
3) “Кроме того, заточен он именно на выполнение типичных операций с данными” – С положительной стороной этого в Вашей разработке я согласен. Поэтому и поставил плюс в рейтинг. Однако конкретная заточка в моём решении прямого доступа к таблицам легко делается на уровне языковых средств 1Са и у меня в конфигурации она сделана.
4) “вместо ручного написания алгоритма на 1С” – Это классическое заблуждение о том, что можно писать эффективные информационные задачи на SQL без знания схемы базы данных, основ СУБД, особенностей работы движка и т.д.
5) “запрос, который преобразуется практически в такой же алгоритм” – Алгоритм запроса из наших примеров преобразуется не в меньшее количество операций ввода/вывода, чем у меня написано навигационным способом. Понимание и осознание пользователем того, как преобразуется алгоритм запроса, часто требует больше усилий, чем это требуется для написания задачи навигационным способом. Количество нажатых кнопок на клавиатуре не сильно отличается. Ну и самое главное. Навигационным способом доступа к данным можно написать любую задачу (в нашей специальности) с гарантированной самой высокой производительностью, на что способен движок. Иными словами. Если существует запрос, то всегда можно написать эту задачу навигационным способом и это будет работать также или быстрее. При этом затраты на написание алгоритма отличаются не значительно (см. наши примеры). Это особенно справедливо, если схема базы данных заточена под навигационные алгоритмы обработки данных, как это сделано в “1С 7.7”.
6) “но еще и выполняемый гораздо быстрее и эффективнее” – Это неправда. Запрос, в данном контексте, не при чем.
В заключение этого, моего сообщения, хочу повторить еще раз, что в части прямых запросов в Вашей разработке - это косметика для продукта, который надо либо выбросить, либо вносить существенный изменения. Либо продолжать считать 1С 7.7 игрушкой для использования, образно говоря, в монопольном режиме в качестве текстового редактора.
Буду тестить и активно вкуривать...
ПОТОМУ ЧТО 8-КА МЕНЯ НЕ ПОРАДОВАЛА СВОИМ БЫСТРОДЕЙСТВИЕМ...
Интересны результаты на нормальных базах, а то я только на демке ТиСа проверял.
Да, там если фильтр по товару ставить, немного лишних данных может вылазить, не обращайте внимания, я попозже поправлю.
В этом случае получаем Резерв = Выписано * КоличествоСтрокСДаннойНоменклатурой. (В общем-то случай частный...).
По скорости со штатным запросом сравнивать смысла нет - отрабатывает мгновенно.
я догадываюсь, но хочется определенности...
Не по словам суди, а по делам.
Ты ведь пример отчета запускал. Костыль это или сервомоторчик?
К тому же можно взять, и запустить код из (30), (32), (46), замерить время.
Больше кому-то что-то доказывать я не собираюсь.
Молча делаю свою работу.
В типовой ТиС (по крайней мере в той версии, что у меня есть (9.2 7.70.947)) для этого отчета не совсем оптимален регистр Заявки и ЗаказыЗаявки.
Если в регистре Заявки у измерения ЗаявкаПокупателя включить "Отбор движений", в ЗаказыЗаявки у измерения ЗаявкаПокупателя поставить "Отбор итогов", и слегка переписать запрос, можно добится еще большей скорости выполнения отчета.
(57)
А вот это радует.
Если я правильно понял, можно использовать с 1С твой движок, и моя компонента все-равно будет работать?
“можно использовать с 1С твой движок, и моя компонента все-равно будет работать?”
Никаких противоречий для этого нет. Ошибки, конечно, могут выскочить. Но их проявление, думаю, будет очевидным сразу. И мы с Вами их быстро исправим, каждый со своей стороны.
“Больше кому-то что-то доказывать я не собираюсь”
Действительно, думаю, доказывать не надо. Но обсуждать “теорию”, а не только “практику” – имеет смысл.
“Молча делаю свою работу”
Уважаемый Александр. Это зря, в смысле “молча”. Думаю, Вашу разработку совершенно реально “подвинуть в направлении” клиент/серверной технологии “рвущей как тузик грелку” SQLную версию “1С 7.7”. И не только в части участков, которые можно написать на прямых запросах, но и в целом. Но это решать только Вам. Надумаете – пишите, звоните…
Навигационный способ, в части чтения:
1) Установить позицию на запись в таблице по ключу индекса или номеру записи.
2) Переместиться по таблице на N записей к началу или концу таблицы от текущей записи в порядке индекса или физическом порядке.
3) Установить позицию на начало или конец таблицы в порядке индекса или физическом порядке.
Моя основная мысль в данном осуждении, что утверждение Александра “запросы рвут язык 1С как тузик грелку” есть самообман. Я считаю, что в языке 1Са не хватает навигационных команд для написания полноценных и эффективных алгоритмов. И запрос к этому не имеет никакого отношения. Запрос в данной разработке лишь использует полный набор навигационных команд. Возможно не всегда оптимальным образом. Писать алгоритм в виде заброса или непосредственно навигационными командами – дело вкуса. Однако при написании алгоритма непосредственно навигационными командами можно всегда обеспечить максимальную эффективность.
Далее мы сползли на обсуждение моего “прилепленного” движка, т.к. в нем, кроме всего прочего, есть расширения стандартного языка 1Са в части прямого доступа к таблицам навигационными командами. Естественно, далее я стал говорить о “всем прочем” в моей разработке. И пытаюсь подвести собеседника к тому, что мной изготовленные “костыли” имеют большее значение, чем средства написания алгоритмов выборки. Т.е., что “содержание” важнее “формы”. Хотя и признаю, что “форма” в этой разработке сделана хорошо.
На вопрос “обсуждение чего идет..?” затрудняюсь ответить. Обмен текстами идет, но, по-моему, в разных темах. :-(((
Кстати. Использование разработки 1SQLite не отменяет возможности использования моей разработки в части режима клиент/сервер. Единственно, что запросы будут выполняться на стороне клиента. Т.е. в чистом виде будут давать только удобство их написания, а не повышать эффективность системы в целом как это задумывалось для клиент/серверной технологии. При этом если, в моей разработке на CodeBase использовать не клиент/серверный режим (у меня это названо – ПДБД) в режиме терминал сервер, то все мои доработки остаются в силе в части:
1) Снятия ограничения на размер таблицы.
2) Устранения клинчей.
3) Разгрузка 100% занятости процессора.
4) Более высокая скорость работы движка.
5) Решение проблемы потери эффективности для больших таблиц.
6) Неограниченное количество пользователей (бесплатно).
7) И т.д.
Кроме этого можно использовать одновременно с 1SQLite и мои расширения штатного языка 1Са в части прямого доступа к таблицам.
если есть возможность: поясните ценность "навигационного подхода" и его пользу при работе по поиску и выборкам данных по сложным условиям... как-то я слабо себе представляю ценность перемещения "навигационным подходом" по базе данных за исключением прямых выборок доков/справочников... или я чего-то не понимаю...?
в свое время писал небольшую СУБД, где все работало безо всяких ключей/индексов - привязка шла исключительно по физическим номерам записей - все просто летало... но процедура реструктуризации базы жмакала долго...
Сергей, и Вам спасибо за проявляемый интерес к данной теме.
Этот, на первый взгляд, простой и короткий, вопрос имеет длинный ответ. Правда, ответ то же простой и от этого излагать его сложно. У меня был случай, когда я целый месяц по 14 часов в сутки рассказывал “ЭТО” высококлассному программисту применительно к АСУпным задачам в части “SQL или не SQL”. Начинать надо с самого начала.
Чем отличаются (в части обработки данных) задачи АСУп от ИПС.
В ИПС требуется искать (выбирать) “вдоль и поперек”. Единственно (упрощаю изложение!), что можно сделать для ускорения обработки это построить индексы с простым индексным выражением. Тем самым уменьшить количество просматриваемых записей – установить по одному реквизиту позицию по ключу и далее двигаться по таблице, выполняя “лобовое” сравнение остальных реквизитов самой записи. Если говорить о наших задачах, то отчеты это ИПС.
В АСУп очень много алгоритмов выполняющихся регулярно по жесткому алгоритму. И для уменьшения количества просматриваемых записей вполне реально построить постоянные индексы со сложным индексным выражением. Приведу пример индекса для получения должников, при условии, что итоги хранятся в самом справочнике клиентов:
IIF(Отгружено>Оплачено,”-“,IIF(Отгружено<Оплачено,”+”,” “))+STR(ABS(Отгружено-Оплачено),15,2)
Т.е. для просмотра списка должников достаточно выполнить позиционирование по “-” и перемещаться в любом (!) направлении без предварительной выборки в массив. При этом количество просматриваемых записей будет равно количеству должников. Если говорить о наших задачах, то использование таких “индексов” это все остальные задачи кроме отчетов. Но можно использовать такие индексы и в отчетах с фиксированным алгоритмом основных критериев отбора.
Т.е. суть разницы между ИПС и АСУпом в части обработки данных это - где лежит само условие выборки – в алгоритме (условие запроса) или в данных (индексное выражение). При проектировании схемы базы данных необходимо учитывать это. Для универсальных систем, таких как “1C:Предприятие” это не простая задача. А если ориентироваться на движок, который не позволяет строить сложных индексных выражений, часто и вообще не решаемая задача. Что мы и видим в SQLной версии 1Са.
Вот такое начало моего ответа на Ваш вопрос. Дальше продолжать?
Универсальную систему (типа 1С) на таких индексных выражениях не сделать. Приведенный тобой пример очень упрощен.
Хотел бы я посмотреть, как построить индексное выражение для поиска должников, если у одного клиента 6 отгрузок с разными датами и разными сроками кредита, 8 оплат разнесенных по разным договорам, да еще и накопительные бонусы какие-нить.
“Приведенный тобой пример очень упрощен.”
ЭТО ПРИМЕР !!!!!!! ;-)))))))))))))))))))
“Универсальную систему (типа 1С) на таких индексных выражениях не сделать”
См. в (63) последний смысловой абзац, три последних предложения.
(68)
“почему же тогда все стараются использовать декларативные методы вместо процедурных?”
Ответ очевидный – это проще в написании на проблемном уровне.
“Мне в своё время пришлось много поработать с BTreeve, и восторга от этого я как-то не испытывал.”
Ну, наверно Вы решали проблемную задачу, а не писали движок к SQLному серверу.
“На SQL я делаю то же самое, но быстрее, и с меньшими травмами мозга.”
“Да, при этом я в любой момент могу досконально разобраться,”
Естественно. См. предыдущий абзац.
Я, в данной теме, “поднимаю” совершенно другой вопрос:
1) Есть универсальная система, заточенная на навигационные методы обработки информации (назовем это НМОИ).
2) Заточено под НМОИ и язык, и возможности строить и менять схему базы данных.
3) В скрытых от пользователя (это мы с Вами) элементах схемы базы данных и методах обработки тоже сделано под НМОИ. Но без “полного” использования его (метода) как в части схемы базы данных, так и в, предложенных пользователю, функциях обработки информации.
4) Было бы логично, продолжая основную концепцию данной универсальной системы, расширить язык 1Са в сторону “полного” НМОИ. А потом это “накрыть” удобным языковым интерфейсом. Да хоть и SQLем.
5) В результате пользователь получил бы, на мой взгляд, систему “два в одном”. И он выбирал бы, в каком случае, чего использовать. А случаев для использовании “полного” НМОИ в 1С достаточно. Например (первое и наглядное, что мне пришло в голову) - динамические фильтры на журналы и справочники.
Но по большому счету “в моей голове подняты” другие вопросы:
1) Написанный на SQL движке (!) для системы с идеологией НМОИ вариант 1C – “1С:Предприятие SQL”.
2) Трех уровневый монстр, в части СУБД, в лице 1С 8.х.
3) Отсутствие полноценной клиент/серверной СУБД с двумя методами доступа к данным – НМОИ и язык запросов.
4) Затратный способ (покупка железа, написание прямых запросов, обработок по свертки БД и т.д.) для приведения скорости (в широком смысле этого слова) работы 1С продуктов к декларированным задачам.
5) И т.д. в этом же направлении…
А что касается данной разработки – плюс в рейтинг я поставил. Несмотря на то, что вопрос расширения языка 1С в сторону НМОИ для повышения её производительности сделан, как минимум, в трёх разработка несколько лет назад. И что касается моих разработок, то мне бы хотелось с автором данной разработки расширить мои языковые средства в сторону SQLя. Тем более что я уже пытался сделать интерпретатор SQL запросов с применением SQLite для своих разработок. Но у меня получилось, так, что больших удобств пользователь не получал.
Александр.
Возможно, то о чем я говорю проясниться, если Вы загляните в описание API для Advantage. И начнёте его смотреть вот с этого:
Skips the given number of records:
UNSIGNED32 AdsSkip (ADSHANDLE hObj, SIGNED32 lRecs);
hObj - Handle of table, cursor, or index order.
lRecs - Number of records to skip (can be negative).
Т.е. в интерфейсе этой СУБД совмещен навигационный и запросный способ обработки информации. Общие транзакции, блокировки, “логика” индексов и т.д. Похоже, что, пока это единственная СУБД с такими возможностями. И, на мой взгляд, это наиболее походящая СУБД для универсальных систем типа 1С 7.7, 8.х. Т.е. вполне реально штатный язык пользователя 1С отобразить на функции СУБД “более прямым способом”.
интерес есть, потому как постоянно хочется "попрограммить" для души - но удается редко, потому как больше востребованы именно "1Сные" задачи (постанови и развития учета), более тонкие моменты (оптимизация, ускорение, увеличение эффективности) - это задачи не "первой необходимости", и, как правило , если такая задача у организации стоит - то, скорее всего, уже и есть решатель...
То есть такой запрос
//**********************************
SELECT
Ост.Товар [Товар :Справочник.Товары],
Ост.Товар.Артикул
FROM
РегистрИтоги_ОстаткиТоваров as Ост
//**********************************
не выполняется, выдавая ошибку: no such column Ост.Товар.Артикул.
А то было бы круто.
Хотя и так, круче некуда.
Спасибо большое!! :D
Нет, не делается. Это не восьмерка и не запросы семерки.
| Код |
|---|
SELECT
Ост.Товар [Товар :Справочник.Товары],
Т.Артикул
FROM
РегистрИтоги_ОстаткиТоваров as Ост left join Справочник_Товары Т on Ост.Товар = Т.id
Показать полностью |
Навигационный метод получения данных это конечно здорово и всё такое. Знать как это работает действительно необходимо, и без этого никогда не решишь задачу методами декларативными. Но вот вопрос: почему же тогда все стараются использовать декларативные методы вместо процедурных?
Мне в своё время пришлось много поработать с BTreeve, и восторга от этого я как-то не испытывал. На SQL я делаю то же самое, но быстрее, и с меньшими травмами мозга. Да, при этом я в любой момент могу досконально разобраться, во что раскрутится мой запрос, но в большинстве случаев это не требуется.
P.S. Это ни в коем случае не упрёк или наезд. Это просто реплика из зала. Личное мнение на основе личного опыта.
В дополнение к моему ответу в (71) для ADirks:
“…при этом я в любой момент могу досконально разобраться, во что раскрутится мой запрос…”
Занимаясь поиском ошибки из моего сообщения (82) я обнаружил, что количество операций чтений справочника “Номенклатура” в примерах (30) и (46) различается в два раза не в пользу запроса.
“Можешь показать, как ты обнаружил разницу в количестве операций чтения справочника?”
Ссылка:
Файл: DBEng32.doc.
Раздел: “Настройка”
Пункты про “Строка № 7” и “Строка № 8”.
Если нет времени заниматься установкой сервера БД (для сравнения) то можно:
1) Использовать версию для CodeBase 6.5 c режимом ПДБД.
2) Мне выслать Вам результат выполнения моего примера из (46).
Ну, а для не сравнения, а анализа установка сервера БД не требуется.
Но меня больше интересует Ваш ответ на (94). Не в смысле делать это сейчас, а в смысле обсудить. Возможно, и другие алгоритмы Вашей разработки упростятся. И это повлияют на написания того, что Вы делаете сейчас по основной теме разработки. Ну, а если не повлияет, то можно и отложить…
Ну, я примерно понял в чем дело.
При соединении со справочником по id движок запросов вынужден считывать запись, следующую за найденной, потому что нигде не указано, что индекс по id уникальный, то есть нет гарантий, что в таблице нет повторяющихся id. Я не считаю это большой проблемой. По крайней мере, в гипотетической ситуации задвоения айдишника в справочнике, запрос отработает фактически верно, в соответствии с реальными данными. Хотя можно и доработать компоненту, условно считать индексы по id справочников, iddoc в журнале и шапках документов уникальными.
“движок запросов вынужден считывать запись, следующую за найденной”
Ну, если еще и это делает, то в 4 раза больше чтений. Запустите трассировку. Там много еще другой полезной информации. Но ответ на вопрос из (106->94) хАчу...
Таки я не понял, в два или в четыре?
Ты в первый раз трассировку плохо посмотрел?
Был бы очень благодарен, если бы ты кинул мне на orefkov gmail.com трассировки для запроса и для подсчета твоим способом.
И замеры времени выполнения обоих способов.
Дико извиняюсь, но тебе сделать это проще, чем мне.
“Таки я не понял, в два или в четыре?”
Если рассматривать то место, которое я смотрел, когда говорил в два раз – то в два раза.
А если учесть то, что написано Вами в (107), то еще в два раза. Т.е. в результате – в четыре раза.
“И замеры времени выполнения обоих способов.”
Это шутка? Я уже писал, что у меня нет большой базы в типовой ТиС. А на демо-версии у меня всё выполняется одинаково – около 0 секунд. И отличия на уровне ошибки измерения.
“если бы ты кинул мне”
Кину в течение ближайшего часа.
“Дико извиняюсь, но тебе сделать это проще, чем мне.”
Нам надо не извинятся, а переходить на более оперативные средства общения. Уж больно много времени уходить на написание буковок.
Буду ждать.
А "отличия на уровне ошибки измерения" - ну так смотря чем и как мерять.
Если использовать _GetPerformanceCounter, который меряет с точностью до мсек, да прокрутить в цикле 10000 раз, то что-то все равно ведь выйдет?
“ну так смотря чем и как мерять”
Вот именно “как”.
“Если использовать _GetPerformanceCounter,”
,а не чем!
“в цикле 10000 раз, то что-то все равно ведь выйдет?”
Нет.
(112)
“Ну, для начала надо иметь список методов, которые подменяет твоя разработка”
Все.
“то бишь какими именно штатными методами и свойствами dbeng32 можно оперировать.”
Любыми.
Но для начала надо брать описание схемы базы данных не из управляющих блоков CodeBase-а.
Я, в своей, разработке беру эту информацию из 1CV7.DD. Это то, что я увидел при беглом (!) просмотре исходных текстов 1SQLite.
"Но для начала надо брать описание схемы базы данных не из управляющих блоков CodeBase-а."
Можно объяснить подробнее, что имеется ввиду?
Из схемы базы данных я беру только состав полей и индексов для желаемой таблицы, черех объекты CTable, CIndex, CField.
Из наполнение будет отличаться при работе твоей версии dbeng32.dll ?
Александр.
Вы читали моё сообщение (94) по поводу ошибки в совместной работе наших разработок?
“Можно объяснить подробнее, что имеется ввиду?”
Вот это:
char* recordBuffer() const {return *(char**)((*(char**)((**(char***)(((char*)p_1C) + 0xC)) + 0x1C)) + 0x14) + 1;}
“…будет отличаться при работе твоей версии dbeng32.dll ?”
См. (113) ответ на (112). И если чего не заработает, то только из-за моей опечатки в программе. Но это быстро мной исправится.
Никак не вижу связи между "recordBuffer()" и 1CV7.DD.
Это просто получение адреса буфера, куда складываются данные записи после перемещения по таблице.
Если отказаться от этого, придется переписывать многое в части получения значений полей записи.
Либо как-то от твоего движка узнать адрес буфера с записью.
“Никак не вижу связи между "recordBuffer()" и 1CV7.DD”
Я ранее написал “при беглом (!) просмотре исходных текстов 1SQLite”. И если не требуется никакой другой информации из управляющих блока кроме адреса буфера ввод/вывода CoseBase, то и не надо использовать 1CV7.DD. А получать это штатным способом (CTable, CIndex, CField).
“Либо как-то от твоего движка узнать адрес буфера с записью”
При использовании моей разработки не используется буфер ввод/вывода родного CodeBase. И для того, чтобы не связываться с ним, надо использовать методы FX_… из CstoreObj. В родной DBEng32 содержание буфера, в общем случае, не предсказуемо. Т.е. они выполняют ввод/вывод средствами CodeBase в буфер и ничего не знают о его местоположении в памяти и сразу выполняют пересылку нужных полей из буфера в переменные 1Са методами FX_… до выполнения следующей операции ввода/вывода для этой же таблицы. А в методах FX_… используются функции CodeBase получения значения поля по его имени.
можно примерчик, как хотябы осв по счету сделать (например остатки по складу)... или как сделать аналог СКД(Счет,ТипСуммы,Валюта,Субконто)
select
Docid,
ktsc0,
accdtid
from Проводки
where DATE > 20080427 and DATE < 20080629 and accdtid = ' N'
где N - идентификатор счета10.1
я на правильном пути ?
импорт файлов возможен с помощью консольной программы sqlite (
но этот способ не очень красив так как для этого придется предварительно создать таблицу с нужной структурой
я могу предложить способ который использую я при работе с файлами типа csv
| Код |
|---|
_итз.ИзФайла(ИмяФайлаДанынх,4);
_итз.Выгрузить(тзДляУкладки);
Показать полностью |
ИндексированнаяТаблица очень быстро работает на загрузку данных из csv
select
SC0 [Мат_вид:Справочник.Материалы],
SC0 [мат:Субконто], obdt1,
SC1
from Остатки
where accid = ' N' and DATE = 20060101
как получить колонку с материалами ?
Для типизации Субконто в колонках запроса должно присутствовать поле ИмяПоляССубконто_вид, содержащее вид субконто. те
select
SC0 [мат:Субконто],
VSC0 [мат_вид]
obdt1,
SC1
from Остатки
where accid = ' N' and DATE = 20060101
Не, там типизация гораздо быстрее происходит.
Однако повторюсь, такую типизацию можно применять, только если
1. Вы точно уверены, что в SC0 будут всегда значения одного, нужного вам вида субконто. (например, у вас есть фильтр по конкретному счету)
2. Тип значения этого вида субконто - справочник, документ конкретного вида.
(Если тип значения этого вида субконто - просто справочник, документ (без указания вида), тогда можно использовать типизацию
SC0 [Субк1 :Справочник]
SC0 [Субк1 :Документ]
те поле не обрезать до 9 символов, типизировать тоже справочником, документом без указания вида)
Так же, если точно известно, что в полученной выборке будут только субконто одного вида (как в твоем примере), то можно написать и так:
select
substr(SC0, 1, 9) [Мат_вид:Справочник.Материалы],
obdt1,
SC1
from Остатки
where accid = ' N' and DATE = 20060101
В данном случае - под поле субконто 1С отводит строку 13 символов.
Но если тип значения субконто - справочник конкретного вида, она в эти 13 символов пишет внутренний идентификатор элемента без указания вида справочника, те использует только 9 символов.
Типизация :Справочник.Материалы ожидает именно строки длинной 9 символов, и если колонка 13 символов, не делает типизацию.
“Ничего вроде не мешает скачать исходники, собрать отладочную версию и проверить”
Правильно ли я понял Ваш ответ, что Вас не интересует “продвижение” 1SQLite в направлении клиент/серверной технологии с использованием моей разработки?
Дико извиняюсь. Пока на это нет времени.
По 1sqlite у меня есть планы по ближайшему развитию, возможно, после их реализации будет движение и в сторону твоей разработки.
Однако лицензия GPL, под которой выпущена 1sqlite ничуть не мешает начать делать эту работу тебе.
Если есть какие-то непонятные моменты в моем коде, я всегда готов помочь разобраться.
“Пока на это нет времени”
Наверно мне придется ждать.
Т.к. “лицензия GPL, …ничуть не мешает начать делать эту работу...”, но не очень то и помогает. Т.е., притом, что Вы планируете движение в сторону клиент/серверной технологии, заниматься мне самодельщиной, думаю, не стоит. А заняться ошибкой было бы вполне реально. Но…
fatal error RC1015: cannot open include file 'l.rus\afxres.rc'
Чего я делаю не так?
Александр.
Мне удалось собрать отладочную версию. Ошибка найдена: recordBuffer().
При таком подходе к использованию интерфейса DBEng32 Ваша разработка не будет работать с моими разработками. Т.е. работать надо только через штатные методы и свойства этого интерфейса. Чего бум делать? Или не делать…
запрос выдает лишние счета - 01, налоговые счета, причем в некоторых строках со счетом "01"типизировался материал
аналогичные результаты при случае запрос.Подставлять("accid", СчетПоКоду(10.1,"Основной"));
Так работает?
| Код |
|---|
ТекстЗапроса = "select
|substr(SC0, 1, 9) [Мат_вид:Справочник.Материалы],
|obdt1,
|SC1
|from __1S_BKTTL Остатки
|where accid = :выбСчет and DATE = :выбДата";
запрос.Подставлять("выбСчет", СчетПоКоду("10.1", "Основной");
запрос.Подставлять("выбДата", '01.01.2006');
тз = запрос.ВыполнитьЗапрос(ТекстЗапроса);
Показать полностью |
- Исправлена ошибка обработки NULL значений.
- Исправлена ошибка преобразования из utf-8 нулевых строк
- Устранена гигантская утечка памяти при некоторых случаях использования LIMIT
- Рефакторинг классов базы данных и запросов, с целью облегчения использования
их в других компонентах
- Из соображений производительности восстановлены типизации :ВидДокумента и
:ВидДокументаПредставление
- Из соображений производительности добавлены типизации :ВидСубконто и
:ВидСубконтоПредставление
Брать
Если используете подзапросы с limit, качать ОБЯЗАТЕЛЬНО!!!
Привожу числа аналогичные Вашим замерам. И не с целю обсуждения “SQL или не SQL”. А как пример безграмотно выполненного тестирования. Обращаю ваше внимание на первые две строчки в каждой группе замеров. Если у Вас появится желание действительно сравнивать производительности наших решений, то давайте обсудим технические условия его проведения. Если Вас заинтересует пояснение данных чисел – задавайте мне вопросы.
1SQLite
Время выполнения запроса: 49 Строк получено: 53
Время выполнения запроса: 3 Строк получено: 53
Время выполнения запроса: 4 Строк получено: 53
Время выполнения запроса: 3 Строк получено: 53
Время выполнения запроса: 3 Строк получено: 53
Advantage 8.1
Время выполнения цикла: 93 Строк получено: 53
Время выполнения цикла: 31 Строк получено: 53
Время выполнения цикла: 31 Строк получено: 53
Время выполнения цикла: 31 Строк получено: 53
Время выполнения цикла: 31 Строк получено: 53
CodeBase 6.5
Время выполнения цикла: 28 Строк получено: 53
Время выполнения цикла: 25 Строк получено: 53
Время выполнения цикла: 25 Строк получено: 53
Время выполнения цикла: 26 Строк получено: 53
Время выполнения цикла: 26 Строк получено: 53
Александр.
А вот так выглядят замеры, если клиента запускать в виртуальной машине, а базу и сервер БД разместить на реальной машине. Но это тоже безграмотное выполнение теста.
1SQLite
Время выполнения запроса: 151 Строк получено: 53
Время выполнения запроса: 113 Строк получено: 53
Время выполнения запроса: 98 Строк получено: 53
Время выполнения запроса: 100 Строк получено: 53
Время выполнения запроса: 99 Строк получено: 53
Advantage 8.1
Время выполнения цикла: 114 Строк получено: 53
Время выполнения цикла: 67 Строк получено: 53
Время выполнения цикла: 70 Строк получено: 53
Время выполнения цикла: 73 Строк получено: 53
Время выполнения цикла: 67 Строк получено: 53
ии попутоно
> "“почему ж на самом деле тормозит 1С:Предприятие” при использовании в качестве написания движка для 1С языка запросов." - ???
“ниччего не понимаю....”
И это радует, т.к. всё понимают только дураки ;-)
Краткое содержание данной темы: “Выяснено, что в Windows, таки, используется кэширование для операций ввода/вывода. И для локальных дисков эффективнее чем, при обращении к дискам через сеть”.
“почему ж на самом деле тормозит”
Одной фразой – реализуют навигационный способ обработки информации запросами.
В “1С:Предприятие 7.7” схема базы данных, алгоритмы обработки данных и язык разработки приложений ориентирован на навигационный способ обработки информации. Причины появления SQLной версии 1Са – клиент/сервер. А клиент/серверных СУБД с языком манипулирования данными отличным от SQL очень мало. Для того чтобы 1С 7.7 эффективно работала на движке с языком манипулирования данными подобным SQLю надо иметь другую схему базы данных, другие алгоритмы обработки данных и другой язык разработки приложений. Т.е. иметь другую 1С.
Вот пара ссылок, в которых есть немного общей информации по этому вопросу. Т.е. прошу не рассматривать эту информацию конкретно как “про Advantage и DBFы”. В контексте этого материала имеет смысл понимать под DBF сам метод доступа к данным – навигационный. Тем более что это уже и не DBFы.
Не хотел вмешиваться.
И я уже “ниччего не понимаю....”
Интуитивно понимая невероятную полезность Вашей разработки, я тщетно ищу жемчужное зерно.
Можно изложить то же самое, но избавившись от логореи?
Из результатов тестов я почерпнул пока только намеки на то, что в SQL первый запрос почти всегда выполняется дольше, чем последующие.
И?
Объясните наконец, в чем сермяжная правда вашего решения?
Понимая, что трогаю Вас за святое, спрошу - как случилось так, что разработки Александра используют многие тысячи людей? А Ваши?
Не обижайтесь, я себя дурачком не считаю и хочу четко и ясно увидеть изюминку.
Бесплатность, скорость, стабильность, отзывы пользователей.
В начале презентации проекта стороннюю заинтересованность видел. Сейчас нет.
???
Примером для разработчиков и пользователей считаю сайт 1С++.
Конструктивная, доброжелательная и очень эффективная по результатам атмосфера.
P.S. Еще раз прошу не обижаться.
Просто тону в потоке мутных сентенций.
“Интуитивно понимая невероятную полезность Вашей разработки, я тщетно ищу жемчужное зерно.”
Уточните, пожалуйста, что Вы в данной теме называете моей разработкой?
“Из результатов тестов я почерпнул пока только намеки на то, что в SQL первый запрос почти всегда выполняется дольше, чем последующие.”
Совершенно верно. И не только в SQL (понимая в разработке 1SQLite).
“И?”
Перечитайте в сообщение (123) первый абзац. Далее посмотрите на замеры в (121), при этом не важно в рамках какой разработки они проводились. А в (124) я пояснил своё высказывание из сообщения (123), проведя безграмотный тест. Далее я написал в (128) суть того, что мы наблюдаем. Т.е. причиной быстрого выполнения НЕ первого цикла любого тестирования по сравнению с первым является системный кэш операционной системы. Только в (121) этот первый цикл (наполнение кэша) произошло при выполнении “запроса” родными средствами 1Са. А в (124) заполнение кэша происходит при выполнении “запроса” сравниваемых способов выборки данных. Т.е. если переставить тесты местами и выполнить их после перезагрузки системы то соотношение 325:2 или 367:30 изменится. И не между сравниваемыми решениями, а в рамках замеров для каждого решения. Уменьшить влияние кэша на “точность” замеров можно запустив тесты в виртуальной сети. Что показано в (125) сообщении. Но все эти замеры в части сравнения разных решений безграмотны, что сказано в сообщении (121) начиная с текста “Заставить заработать AddIn.AddInExt и 1sqlite в одной базе…”. Добавлю только от себя к фразе от Александра “и на разных движках”.
“Объясните наконец, в чем сермяжная правда вашего решения?”
Повторю свой вопрос. Что Вы называете моим решением?
“Понимая, что трогаю Вас за святое…”
Если понимаете, то не трогайте. ;-)))
“…спрошу - как случилось так, что разработки Александра используют многие тысячи людей? А Ваши?”
Я не понимаю этот вопрос. Т.е. не в смысле того, что Вы написали. А в смысле того - почему Вы это написали. У Вас сложилось впечатление, что мы какие то разработки сравниваем? Или, что я критикую разработку Александра? На самом деле я высказал своё мнение в (23) по поводу сообщения (19) от Сергея. Т.к. несколькими днями раньше разговаривали на эту тему. Я даже ссылку поставил. Далее я запустил трассировку операций ввода/вывод средствами своей разработки и в (27) подтвердил свое предположение. Ну а далее по теме, Александр ставил мне задачки – я писал решения. Александр задавал мне вопросы, я отвечал.
“Не обижайтесь, я себя дурачком не считаю и хочу четко и ясно увидеть изюминку.”
”Бесплатность, скорость, стабильность, отзывы пользователей.”
”В начале презентации проекта стороннюю заинтересованность видел. Сейчас нет.”
Если Вы о навигационном способе доступа к данным. То все нарисовано в (46). Если о чем-то другом, то уточните, пожалуйста.
“Примером для разработчиков и пользователей считаю сайт 1С++.”
”Конструктивная, доброжелательная и очень эффективная по результатам атмосфера.”
Согласен. Хорошая атмосфера.
“Просто тону в потоке мутных сентенций.”
И я тону. И как это поправить?
“... надо перечитывать весь сабж...”
Сергей.
Попробую поберечь Ваше время.
1) Используется DBFная версия 1Са. Всех, всё это устраивает, кроме скорости работы. Тогда используйте 1SQLite.
2) Работа в DBFной версии не устраивает. Задумываетесь о переходе на SQLную версию. Тогда переходите на нее и пишите прямые запросы с помощью 1С++.
3) Работа в DBFной версии не устраивает. Задумываетесь о переходе на SQLную версию. Но писать прямые запросы не хотите. Тогда попробуйте связку “DBEng32+Advantage”.
4) Попробовали “DBEng32+Advantage” – устраивает. Но хотите писать прямые запросы. Тогда пишите прямые запросы на 1SQLite. Если будет обеспечена совместимость данных продуктов.
5) Если совместимость не будет обеспечена. А прямые запросы из 1SQLite Вы хотели писать для повышения производительности уже связки “DBEng32+Advantage” то используйте ДУС и РУС из моей разработки.
Вот напиши такой запрос (в терминах 1с++, но думаю, что всё понятно):
SELECT
$Сотрудники.ПолнНаименование
,$Сотрудники.Оклад
,$Сотрудники.id [Сотрудник $Справочник.Сотрудники]
FROM $Справочник.Сотрудники Сотрудники
WHERE Сотрудники.ДатаРождения BETWEEN :НачДата и :КонДата
потом сравни с этим. Что лучше читается? Думаю, что ответ очевиден.
А если ты со своим запросом пойдёшь на другую базу? Заново писАть?
Я разве давлю? Просто ненавижу "эклектику". Всегда бесило, например, Spr=CreateObject("Справочник.Сотрудники")
Поэтому не шибко нравится и FROM $Справочник.Сотрудники
Но это дело вкуса.
Потом я совершенно точно знаю, что делает прямой скуль, и не знаю как там разбирается с запросом 1С++...
Вот теперь полносью удовлетворен ответом. Достаточно коротко и ясно. Спасибо.
Жаль, но для меня работа с dbf не совсем актуальна, иначе постарался бы тему развить.
В сетях с количеством юзеров больше трех стараюсь склонить заказчика на sql. Оно того стоит.
Удачи!
Так что меня FROM $Справочник.Сотрудники не шибко удивишь ;)
В момент выполнения запроса блокируются, некоторые, таблицы БД. Если в другой сессии 1Са будет выполняться попытка обновления таблицы, участвующих в запросе, то эта сессия завершится аварийно с кодом ошибки “CodeBase –56” после ожидания, примерно, 60 секунд.
“т.е. ошибка в "родной" 1С другого сеанса будет если данная сессия "недождется" освобождения таблицы на запись в течение 60секунд ?”
Да.
“эти 60 секунд как-то коррелируют с устанавливаемым параметром "время ожидания захвата таблиц" ?”
Нет.
P.S. Причина известна. От неё можно избавиться. Слово за автором разработки.
При возникновении ошибки описанной в (153) сообщении, похоже, всё гораздо хуже, чем простое сваливание сессии 1С-а!
Примерно так:
При выдаче команд на обновление данных в CodeBase через DBEng32, 1С-ина не всегда проверяет код возврата. И сообщение об ожидании может не выдаваться. Просто часть команд по обновлению данных, молча, не выполняется. А когда доходит дело до выполнения команд, где 1С-ина проверяет код возврата – появится картина, описанная в (153) сообщении.
очень расстроился после сообщения hogik`a об ошибке (153)
однако теплится надежда на то, что я не совсем верно понял ситуацию :)
Уважаемый hogik разъясните пожалуйста, базы портятся при совместном использовании codebase и запросов 1sqlite или при использовании 1sqlite со стандартным движком 1с?
1) Стандартный движок 1С – CodeBase. Не путайте с разработкой “DBEng32 для CodeBase 6.5”.
2) База данных портится при использовании стандартного движка 1С.
3) В версии 1SQLite (1019) проблема решена – см. форум по 1С++.
4) В версии 1SQLite (1018) проблема решена – см. разработку
“выходить нельзя пользоваться sqlite1c в многопользовательке ?”
В текущей версии – не рекомендую.
“или может в момент запроса sqlite1c пробовать транзакцией блокировать необходимые таблицы ?”
Т.е. не только проведение документов делать последовательно между пользователями, но и формирование отчетов. ;-))) Тем более, что это не поможет.
“жесть”
Думаю, в следующей версии Александр исправит эту проблему. Причина, то известна. И не требует больших переделок в разработке.
1. В одной сессии выполняем запрос: "select * from Журнал"
2. В другой в это время выполняем код:
| Код |
|---|
Док=СоздатьОбъект("Документ.Любой");
Док.Записать() Показать полностью |
Готово. (главное, чтоб "Записать()" выполнялась в момент выполнения запроса)
Я правильно понял?
Более очевидный способ – делать это на справочниках. Т.е. я брал запрос из . А в другой сессии выполнял чтение, обновление, добавление, удаление записей. Я написал причину в: , ID=10, последний абзац. И этот сбой соответствует принципам технологических блокировок при работе с DBFами. До недавних пор, просто, не было полной уверенности в том, что 1C-ина делает в этих методах. Теперь уверенность есть :-(((
Провел замеры скорости выполнения запросов в условиях, описанных в .
Получил, время выполнения запроса 2500 секунд.
Это время мало отличается от времени выполнения данной задачи обычным циклом на штатном языке программирования. Т.е. основная причина быстрого выполнения запроса в 1SQLite, это использование методов движка не предназначенных для многопользовательской среды.
Процедура Сформировать()
Спр = СоздатьОбъект("Справочник.ТестВылетов");
Пока 1=1 Цикл
Спр.Новый();
Спр.УстановитьНовыйКод("фыв");
Спр.Наименование = Спр.Код;
Спр.Записать();
//Сообщить(Спр.Код);
КонецЦикла;
КонецПроцедуры
Процедура Сформировать()
База=СоздатьОбъект("SQLiteBase");
База.Открыть(":memory:");
Запрос = База.НовыйЗапрос();
Пока 1=1 Цикл
запрос.ВыполнитьЗапрос("SELECT * From Справочник_ТестВылетов",ТаблЗапроса);
//Сообщить(ТаблЗапроса.КоличествоСтрок());
КонецЦикла;
КонецПроцедуры
Что-то ошибок не выскакивает, база не рушится...
Навероное у меня руки не из того места растут
“Навероное у меня руки не из того места растут”
Думаю, не руки, а глаза.
В (153) написано “…после ожидания, примерно, 60 секунд”. Т.е. это означает, что запрос должен выполняться большее время. А еще можно посмотреть на замеры в для 1SQLite увидеть там время около 180 секунд. Имеет смысл посмотреть, там же, размеры файла DBF и количество записей. Не думаю, что Ваш запрос отбирает 510426 записей в таблицу значений. ;-)
Select sum(Количество) FROM Справочник_Новый1 Новый1 Where Новый1.Количество>=0
две сессии колбасились около 5 минут. Ниодного вылета! Что я делаю не так?
При обращении к таблицам с данными по сети судя по скорости компонента полностью перекачивает таблицу и скорость обработки запроса сравнима с прямым запросом через Microsoft Visual FoxPro Driver или Microsoft.Jet.OLEDB.4.0 (я не использовал 1С++ а только вышеуказанные драйвера-провайдеры)
при локальном запуске 1sqlite примерно на ПОРЯДОК быстрее прямых запросов также запущенных локально
В качестве практической пользы пока реализовал "клиент-сервер" когда обработка на клиенте (сетевое подключение) отправляет сеансу на машине(хранилищу базы) запрос 1sqlite и обратно ей передается ТЗ с данными, работает шустро
А можешь поподробнее? В блоге расписать. Очень интересно что, как и почему.
Но насколько я понял из использовать на промсчете данную разработку пока рисковано? А с другой стороны начальство остерегается пересаживать базу на CodeBase/Advantage поскольку тоже в обсуждениях высказывалось что-то негативное (или даже в самом описании ) и за это платить еще деньги.
Вообще-то у нас dbf база эксплуатируется в терминальном режиме? Подскажите как все-таки безопаснее ускорить работу?
Пока применили Вашу hogik разработку (kernel33) для снятия ограничения 1ГБ - давняя головная боль :( спасибо
1) “…использовать на промсчете данную разработку пока рисковано?” – Разработка “DBEng32 SEQ” не предназначена для “промсчета”.
2) “начальство остерегается пересаживать базу на CodeBase/Advantage” – И это естественно. У нас решение на “CodeBase 6.5” успешно работало ровно год. Сейчас, почти год, успешно работает решение на “Advantage 8.1”.
3) “тоже в обсуждениях высказывалось что-то негативное” – Что?
4) “Подскажите как все-таки безопаснее ускорить работу?” – Самое безопасное ускорение – DBFная версия 1Са в терминальном режиме. Это при малом количестве пользователей и не превышении 1(2) гигабайт на размер таблицы. Далее - SQLная версия 1Са с использованием прямых запросов и увеличением мощности сервера.
Сюда пока не выкладываю, так как еще не все фишки доделал, какие хотел в включить в новый релиз.
Одновременно работает по 50-60 человек;
два четырехядерных процессора;
в пиковой нагрузке конечно же заметно притормаживание системы, а в остальное время, в принципе, приемлемо.
Хотелось бы снять нагрузку за счет, может быть, прямых запросов. Тем более, начальство вычитало статью в журнале "Системный администратор" №7 за 2008, там как раз за это было написано. В статье упоминаются 1sqlite, 1C++, SpellSQL, Rainbow, ToySQL.
2(orefkov)(188)
То есть, теперь можно использовать 1sqlite без использования (181)?
Да, можно.
Более подробно о том, что в (188):
Версия без ReadSequnce.
Добавлено:
- Объект SQLiteQuery. Метод ParseSqlText / ОбработатьТекстЗапроса("текст")
Возвращает переданный текст, обработанный метапарсером.
Установленые для запроса методом "Подставлять" текстовые параметры НЕ СБРАСЫВАЮТСЯ.
- Объект SQLiteQuery. Свойство NeedTransaction / ВыполнятьВТранзакции
Позволяет прочитать/установить свойство.
0 - не начинать транзакцию.
Не 0 - автоматически начать транзакцию при первом обращении к таблицам 1С при выполнении запроса, если она не начата.
В монопольном режиме независимо от значения свойства транзакция начинается ВСЕГДА.
В немонопольном режиме выполнение запроса в транзакции позволяет ускорить выполнение запроса, однако блокирует используемые таблицы для записи.
- Исправлен косяк при укладке объектов, содержащих в идшнике русские буквы.
- Убраны Begin/End ReadSequnce при чтении длинных строк и таблиц справочников при укладке объектов.
- Сделано принудительное округление чисел при типизации :Число, тк получатели
результата (кроме ТаблицыЗначений) сами этого не делают.
- Исправлена работа типизации при обработке NULL значений, тк получатели
результата (кроме ТаблицыЗначений) сами этого не делают.
- Изменена логика работы с Begin/EndReadSequnce. В немонопольном режиме падение
производительности, зато не падает.
- Добавлен метод SQLiteQuery::ОбработатьТекстЗапроса
- Добавлено свойство SQLiteQuery::ВыполнятьВТранзакции
- Исправлена ошибка программы при подключении таблиц шапки документа, не имеющего
реквизитов шапки.
- Исправлена ошибка при выборке из таблиц 1С, иногда могущая привести к зависанию
программы.
- Добавлено подключение таблиц ЖурналовРасчетов ДБФ версии 1С.
- Исправлена укладка списка объектов при наличии иерархии - неверно укладывались
объекты, содержащие в идентификаторе русские буквы (распределенка с русским
префиксом ИБ).
- Добавлен объект SQLiteDataProvider - поставщик данных табличного поля 1С++ для
таблиц sqlite и таблиц 1С DBF-версии.
select d.iddoc [Документ :Документ]
from Документ_РасходнаяНакладная as d
where d.Контрагент = :ВыбКонтрагент"
Запрос пустой :-(
|Период С Дата1 По Дата2;
|Фирма=Регистр.ОстаткиТоваров.Фирма;
|Товар=Регистр.ОстаткиТоваров.Товар;
|Склад=Регистр.ОстаткиТоваров.Склад;
|ДокументДвижения=Регистр.ОстаткиТоваров.ТекущийДокумент;
|Кол=Регистр.ОстаткиТоваров.ОстатокТовара;
| РасхКол=Расход(Кол);
|Функция КонКол=КонОст(Кол);
|Группировка Товар без групп все;
Не понятно как вязать Регистр_ОстаткиТоваров и РегистрИтоги_ОстаткиТоваров... Или это нереальано с помощью Sqlite ?
Или возьми и покумекай класс:
- SQLite обновлен до релиза 3.6.11
- Добавлена способность ПоставщикаДанных динамически менять текст запроса, если
некоторые поля не нужны табличному полю для отображения
- Добавлена возможность быстрого поиска для поставщика данных
- Исправлена ошибка выборки данных при некоторых условиях
(where date <= '09или19или29.месяц.год' order by date desc)
- Убрана странная ошибка при попытке подготовить запросы с текстом запроса длиннее 972 символов.
- Порядок сортировки в 'collate _1C' сделан точно соответствующим порядку сортировки в дбф-файлах 1С.
- Изменены методы:
- SQLiteDataProvider::УстановитьТекстЗапроса
- SQLiteDataProvider::Отладка
- Добавлены методы:
- SQLiteDataProvider::НеУдалятьПоля
- SQLiteDataProvider::ПоляБыстрогоПоиска
- SQLiteDataProvider::ПолучитьТекстЗапроса
Брать на
"Условие (Номенклатура.ПринадлежитГруппе(Молоко)=1)"
Причем группа Молоко многоуровневая
приходится писать что-то подобное...
Процедура УложитьТЗвЛайт(База,_ТЗ,ИмяТаблицы,Врем=0)
Если _ТЗ.КоличествоСтрок()=0 Тогда
_ТЗ.НоваяСтрока();
База.УложитьТЗ(_ТЗ,ИмяТаблицы,Врем);
Запрос=База.НовыйЗапрос();
Запрос.ВыполнитьЗапрос("delete from "+ИмяТаблицы);
Иначе
База.УложитьТЗ(_ТЗ,ИмяТаблицы,Врем);
КонецЕсли;
КонецПроцедуры
Может
SQLiteBase::putVT(CValueTable* pVT, const CString& strNameOfTable, BOOL bAsPersistent)
...
DWORD rows = pVT->GetRowCount();
if(!rows){tg.err = FALSE;return;}
.
РазбиваемаяСтрока=СтрЗаменить(РазбиваемаяСтрока,"'","''");
РазбиваемаяСтрока=СтрЗаменить(СокрЛП(стрПоиска)," ",РазделительСтрок);
- вот тут вот как-то неаккуратненько???
select ФИО, Рез from НужныйСправочник where Рез='+'
Рез - Перечисление "Булево", имеет значения "+" или "-"
В запросе:
AND (ПолеСПеречислением =:Плюсик)Далее:
Запрос.Подставлять("Плюсик", Перечисление.Булево.+);П.С. У тебя прям в конфигураторе в ИД стоит "+"?
Текущая версия 1.0.2.0 bugfix 3
* SQLite версии 3.6.11
(с)
Current Status
* Version 3.6.21 of SQLite is recommended for all new development. Upgrading from version 3.6.12, 3.6.13, 3.6.14.2, or 3.6.16 through 3.6.20 is optional. Upgrading from all other SQLite versions is recommended. (с)
Пытаюсь создать Базу в консоли : на винде получается через три на четвертый(закономерности не заметил) на линухе с первого раза. Из 1С (7,7 ) база создается , но загрузить в нее данные не получается, в какую сторону копать?
Как загрузить данные из виртуальной таблицы в файл базыSQL?
И еще вопрос про относительные пути в 1С 7и 8 ? если обработка запуска лежит в каталоге, отличном от каталога базы , прогФайлов(допустим на флешке) как определить програмно путь до нее? (база естественно будет лежать неподалеку, да и DLL-ка тоже)
База.УложитьТЗ(ТЗ,"ТЗ");
запросSQLLite.ВыполнитьЗапрос("INSERT INTO base Select * From ТЗ");
Уложенная ТЗ - это виртуальная таблица в памяти, чтобы заполнить базу значениями из неё (запросом INSERT)? Т.е. она сама (ТЗ) не сохраняется в базе при укладке?
Смотри внимательнее параметры метода УложитьТЗ, там есть "как постоянную"
т.е. по дефолту таблица под ТЗ создается компонентой как
| Код |
|---|
create temporary tableПоказать полностью |
и автоматом дропается при закрытии базы, а может создаваться как
| Код |
|---|
create tableПоказать полностью |
|INSERT OR REPLACE INTO
| main (< ... тут перечень полей ...>)
|SELECT *
|FROM ТЗ";
тестирую несколько раз - записи каждый раз добавляются. Т.е. как понимаю REPLACE не срабатывает. Что-то не так делаю?
| Код |
|---|
insert into basetable select ... from tzTable
Показать полностью |
а если просто выбрать данные, то
| Код |
|---|
select .... from basetable
union all
select .... from tztable
Показать полностью |
есть описание языка, правда по-аглицки.
1C++ и 1sqlite - это разные компоненты, работающие независимо друг от друга.
Просто с помощью 1C++ сделан класс, автоматически преобразующий текст запроса в версии для sql и dbf. К самой компоненте есть документация, описывающая, как выполнять запросы. Просто надо ещё знать структуру хранения данных в 1С. На форумах по 1С++ есть много информации на эти темы. Можно ещё и на мисте поспрашивать.
1. Всё писалось разными людьми, для разных целей и задач. Не для начинающих.
2. Есть целый форум, посвященный прямым запросам.
3. Классы, в том числе класс ПрямойЗапрос созданы как раз для облегчения написания чего-либо
4. 1sqlite не позволяет строить запросы к сторонней базе, только в родной.
5. Для написания запроса к сторонней базе, для дбф варианта, достаточно иметь компоненту 1cpp.dll, установленный vfpoledb провайдер.
Обо всём, более подробно можно прочитать тут
welcome!
Вам просто лень ЭТО осилить.
Про убогий синтаксис языка запросов снеговика, лучше вообще не стоит упоминать.
А типизация там есть, более того, можно лепить запросы к нескольким базам одновременно.
На вот, занимайся.
2 запроса, один на фоксе, другой на 1sqlite
select distinct
СпрКонтр.Descr as Контрагент,
СпрДог.Descr as Договор,
Sum(iif(покуп.debkred=1, Покуп.Sp2201, -Покуп.Sp2201) )as СуммаПродОстаток,
Sum(Покуп.Sp2201) as СуммаПрод,
Sum(Sp2203) as СуммаСебест,
Max(покуп.SP2198) as [док $Документ ]
from
ra2207 as покуп
LEFT JOIN SC92 as СпрДог
LEFT JOIN SC134 as СпрКонтр
ON СпрКонтр.id= СпрДог.parentext
ON Покуп.SP2195 = СпрДог.ID
left JOIN 1Sjourn as Жур
ON Жур.IDDoc = покуп.SP2198
Group by Контрагент,Договор
{C:\Base77\База\ПрямойЗапрос.ert(1
ПрямойЗапрос::СоздатьОбъектыЗапроса(Строка ПутьКБазеSQL=:memory:) : Неудачная попытка создания объекта
БазаSQLite = СоздатьОбъект("SQLiteBase");
{C:\Base77\База\ПрямойЗапрос.ert(1057) }
Возник вопрос: обновил компоненту с 1.0.2.3 до 1.0.2.6 (запросы работали корректно).
Спустя неделю вылезла проблема с запросом:
|SELECT
| doc as [Реализация $Документ.Реализация],
| doc as РеалId
|FROM
| Sklad
|WHERE
| (date between :НачДатаПров and :КонДатаПров) and (doc=:ПроверДок)
ПоказатьОн просто начал игнорировать часть условия с "(doc=:ПроверДок)" отлавливать такие моменты по всем обработкам возможности нет. Да и на боевой базе нужно чтобы все работало здесь и сейчас.
Решил вернуться на 1.0.2.3 но базы стали "file is encrypted or is not a database".
Нашел 1.0.2.4, но часть запросов, н-р:
|CREATE TABLE IF NOT EXISTS ContrSendConfS (id INTEGER PRIMARY KEY NOT NULL, IdContr INTEGER, IdType INTEGER, IdFormat INTEGER, IdMethod INTEGER, Adress STRING);
Вопрос: как можно вернуться к версии 1.0.2.3?
Заранее очень благодарен!
Последняя выложенная ведет себя, так же, не корректно.
1.0.2.4 - возвращает корректное значение.
Я так понял, что при открытии базы новым sqlite он эту базу конвертировал, но при открытии менее молодой версией обратно он её не преобразовывает. База используется достаточно активно, поэтому бэкапы уже не спасут.
Сейчас пытаюсь набросать обработку, которая пересоздаст базы и перезаполнит (1.0.2.4).
Разработчику постараюсь сообщить.
Но сообщение, о том что грабли с возвратом с нестабильной (по крайней мере пока) библиотеки стоят за углом и ждут, хорошо бы где-нибудь в шапке опубликовать.
В упор типизацию не видел. Сам балбес оказался.
Завтра буду шерстить. На предмет INTEGER id'шников (видимо любые id по привычке как INTEGER заводились).
Странно что 2.3, 2.4 умудрялись корректные данные возвращать.
|SELECT
| Sklad.doc as [Реализация $Документ.Реализация]
|FROM
| Sklad
|WHERE
| (Sklad.date between :НачДатаПров and :КонДатаПров)
//| and (Sklad.doc=:ПроверДок)
| and (Sklad.doc LIKE '%'||:ПроверДок||'%')
ПоказатьТ.е. проблема явно связана с непечатными символами в базе (очень похоже на то, что начиная с какой-то версии при выполнении запроса к базе
ЗапросSQLite.Подставлять("ТекВремя",ТекущееВремя());
ЗапросSQLite.Подставлять("ТекДата",ТекущаяДата());
ЗапросSQLite.Подставлять("ТекДок",Док);
ТекстЗапроса="
|INS ERT IN TO Sklad (time, date, given, doc) VALUES (:ТекВремя,:ТекДата,0,:ТекДок);
|";
ПоказатьВ результате 1E4RS из-за динамической типизации sqlite остается строкой и запрос выводит правильное значение, а 1E702 из-за указанной типизации integer становится числом, но sqlite не поддерживает 10 в 702 степени и запрос работает не так как хочется.
2. Понизить версию базы после запуска на 1.0.2.4-1.0.2.6, чтобы запустить на 1.0.2.3, возможно. Нужно изменить хекс редактором байты по адресу 0х12 и 0х13 с 0х02 на 0х01
Обязательно сделайте копию! Гарантии работоспособности такого варианта нет.
Нет желания создать на ИСе свою публикацию со своими доработками 1sqlite? Я бы против нисколько не был.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 15977
Создание 23.06.08 13:45
Обновление 01.02.12 13:24
Просмотры 79218
Загрузки 6072
Рейтинг
143
Комментарии 290
Код открыт Не указано
Рубрики Внешние источники данных Разработка внешних компонент Файловый обмен (TXT, XML, DBF), FTP
Кому
Системный администратор
,
Разработчик
Тип файла Компонента, плагин (dll, vbs,..)
Платформа
Оперативный учет 7.7
,
Бухгалтерский учет 7.7
,
Расчет 7.7
Конфигурация 1C77
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)