А реально ли сделать "УложитьИТЗ" по анологии с "УложитьТЗ"? И, если у ИТЗ были индексы, то чтоб и в таблице Sqlite они тоже создавались.
Но, т.к. ТЗ преобразуется при укладке в зависимости от имён колонок, а у ИТЗ нет заголовков, то, вероятно, надо будет добавлять входные параметры.
Хотелку оформлять или не стОит?

orefkov писал(а) 08. Июля 2008 :: 11:25:

Переход в конец журнала при нажатии End на клавиатуре выполняется очень долго.
При этом потребление оперативы вырастает на ~60М (в моей базе), одно из ядер процессора нагружается на 100%, из таблиц DBF почти ничего не читается.
Съеденная оператива не отдается после позиционирования в конец списка, а отдается только при закрытии ТП.
Изменено:

steban писал(а) 08. Июля 2008 :: 11:59:

Хм...
А движок SQLite (или 1sqlite) кэширует данные из виртуальных таблиц?

orefkov

Саня, да, есть такое дело, о котором говорит Степан.
У меня, правда, память освобождается при переходе в начало (Home).
Плюс промотка снизу вверх (от конца в начало) постоянно увеличивает working set - плохо.

Комментарии к рисунку:
1. открылась форма с ТП, нажали End
2. нажали home
3. нажали End
4. нажали Home
5. нажали End
6. закрыли форму.

Замерялось в монопольном режиме. База на локальном винте.
может поможет в разборках.

kms писал(а) 08. Июля 2008 :: 12:45:


Текст исходного запроса не анализируется. Просто добавляются условия по ключевому полю через and.
Для диагностики есть метод Отладка(КакиеЗапросыОтлаживать, Режим)
Вызывать перед УстановитьТекстЗапроса

В поставщике могут подготавливаться 5-6 запросов. Для каких запросов включить отладку, задается параметром КакиеЗапросыОтлаживать, суммой чисел
1 - запрос на получение первых записей
2 - запрос на получение последних записей
4 - запрос на получение следующих записей
8 - запрос на получение предыдущих записей
16 - запрос на обновление текущей строки
32 - запрос на поиск записи по ид-полю
те написав
пост.Отладка(7, 1)
отладим первые три запроса.

Ну чтож, нашел кучу багов. Пофиксил. Тестируем поставщика дальше?

Вопрос к знатокам поставщиков. Есть у ТП такой метод, как ТекущаяСтрока. Если пользователь пишет
тп.ТекущаяСтрока = выбЭлемент
мне надо по переданному значению определить ключ нужной записи.
Сейчас это делается убого, и может привести к full-scan'у.

Например, такой запрос (вывод справочника с иерархией):

|select
|id [Номенклатура :Справочник.Номенклатура],
|code [Код],
|descr [Наименование],
|case when isfolder = 2 then '' else '+' end [ЭтоГруппа],
|Артикул,
|БазоваяЕдиница [БазоваяЕдиница :Справочник.Единицы],
|idx_parentid_isfolder_descr key
|from Справочник_Номенклатура Н
|where parentid = @parentid
 

Пользователь задает ид-поле - [Номенклатура :Справочник.Номенклатура].

То есть возникает задача - если мне передали id, надо вычислить для него idx_parentid_isfolder_descr.
Сейчас это решается так:
выполняется запрос

|select
|id [Номенклатура :Справочник.Номенклатура],
|code [Код],
|descr [Наименование],
|case when isfolder = 2 then '' else '+' end [ЭтоГруппа],
|Артикул,
|БазоваяЕдиница [БазоваяЕдиница :Справочник.Единицы],
|idx_parentid_isfolder_descr key
|from Справочник_Номенклатура Н
|where parentid = @parentid and [Номенклатура :Справочник.Номенклатура] = @idvalue
|order by key limit 1
 

Как видите, не самый оптимальный вариант, оптимальней было бы

|select idx_parentid_isfolder_descr
|from Справочник_Номенклатура Н
|where id = @idvalue limit 1
 

В примере с документами по графе отбора ситуация еще хуже.

Я совершенно не представляю, как автоматом из исходного текста запроса и названия ИдПоля сгенерить оптимальный запрос для получения ключа порядка по значению ИдПоля.
Может, при указании ИдПоля задавать еще и запрос для нахождения ключа по ИдПолю?