про BufferChunks - это просто буфер (блок) для считывания пачек записей.

Док, если ты решил отказаться от dbaware-компонентов, то и наследник датасета (TIBQuery) тебе нахрен не нужен.
он выполняет туеву хучу дополнительных раундтрипов из-за того, что так положено датасету для поддержки dbaware.
пользуй TIBSQL.

В моем случае, если я заполняю дерево и прикручиваю к нему пагинатор после 100 записей, то получается в цикле надо будет 100 запросов выполнить, предварительно отпрепарировав текст?

послушай сюда.

procedure TForm1.Button1Click(Sender: TObject);
begin
  if not IBDatabase1.Connected then IBDatabase1.Connected:= True;
  try
    IBTransaction1.StartTransaction;

    MemDataset1.Active:= True;

    with IBSQL1 do
    begin
      SQL.Text:= 'SELECT COUNT (ID) ID FROM TEST';
      ExecQuery;
      Label1.Caption:= 'Record count = ' + FieldByName('ID').AsString;

      SQL.Text:= 'SELECT ID, NAME FROM TEST';
      Prepare;
      ExecQuery;

      while not IBSQL1.Eof do
      begin
        MemDataset1.AppendRecord([FieldByName('ID').AsInteger, FieldByName('NAME').AsString]);
        Next;
      end;
    end;
    IBTransaction1.Commit;
  except
    on E:Exception do
    begin
      IBTransaction1.Rollback;
      ShowMessage(E.Message);
    end;
  end;
end;

Показать скрытый текст

Пагинаторы забудь как страшный сон. Они только хуже делают. Раз у тебя дерево - твой путь загружать детишек по мере раскрытия веток. Это если, конечно, твоё дерево изначально свёрнутое, в противном случае - грузи всё сразу. Гуй тормозит сильнее базы.

тогда все ясно. Дим, а ты можешь в статье правку сделать для полного понимания тем, кто тоже читать статью будет?

Предполагается, что рут-записей будет много, неужели все грузить (даже в свернутом виде)?

извиняюсь, прорвало. Вспомнилось, как некто мне на семинаре Эмбаркадеры про приложения на мобилах говорит
- я вот тут в список загрузил 1000 (или 10к) строк, и он тормозит.
Ну ёп... Ты этот список зачем вывел, чтобы что? Чтобы юзер убился, оплевался, и проклял того кто выводит 1000 элементов на экране планшета или мобилы?

Ну допустим, не весь список а "пагинатор" - зачем, для чего, чтобы что?

кстати, по поводу RecordCount.
Слава богу, это свойство приводит к "внутреннему" Select count только для IBTable. Остальные датасеты тупо показывают количество отфетченных на текущий момент записей в кэш датасета (IBDataSet, IBQuery). Которые кладутся в буфер датасета (не в BufferChunks). Грубо говоря, Last/FetchAll и RecordCount покажут, сколько всего было выбрано записей "на клиента", в локальный буфер. После чего Next, Prev, First и Last будут елозить по этому буферу, без обращений к серверу, совсем.

Тут проще посмотреть код Locate. Оно пытается фетчить всё, или нет - я х.з.

Док писал(а) Fri, 20 January 2023 15:49

Предполагается, что рут-записей будет много, неужели все грузить (даже в свернутом виде)?

1. нахрена тебе select count. Сделай select корневых записей, потом Last (или fetchall), возьми recordcount.

кстати, по поводу RecordCount.
Слава богу, это свойство приводит к "внутреннему" Select count только для IBTable. Остальные датасеты тупо показывают количество отфетченных на текущий момент записей в кэш датасета (IBDataSet, IBQuery). Которые кладутся в буфер датасета (не в BufferChunks). Грубо говоря, Last/FetchAll и RecordCount покажут, сколько всего было выбрано записей "на клиента", в локальный буфер. После чего Next, Prev, First и Last будут елозить по этому буферу, без обращений к серверу, совсем.

Что-то мне тред напоминает беседу еще чуть ли не времен FIDO... В подходах за это время ничего не поменялось, если что.

Что-то мне тред напоминает беседу еще чуть ли не времен FIDO...
В подходах за это время ничего не поменялось, если что.

Что-то мне тред напоминает беседу еще чуть ли не времен FIDO... В подходах за это время ничего не поменялось, если что.

- VirtualTreeString заполняется 1'000'000 записей из memdataset за 4 сек. Причем скроллируется этот миллион в гуе без каких-либо лагов и артефактов!

- IBSql фетчит и помещает в memdataset 1'000'000 записей
...
- VirtualTreeString заполняется 1'000'000 записей из memdataset за 4 сек.

Второй пункт вредный. Понижает реактивность интерфейса. Пользователи не любят когда кнопки лагают.

SD

Второй пункт вредный. Понижает реактивность интерфейса. Пользователи не любят когда кнопки лагают.

рюмка водки crSQLWait на экране снимает симптомы обсессивно-компульсивной тревожности.

1. Зачем тут датасет??? Хочется помедленнее и пообъемнее?
2. Зачем заранее загружать поля записей, которые не видны на экране? Загружай, когда контрол об этом попросит, и кэшируй значения.

Цитата:

1. Зачем тут датасет??? Хочется помедленнее и пообъемнее?
2. Зачем заранее загружать поля записей, которые не видны на экране? Загружай, когда контрол об этом попросит, и кэшируй значения.

Подскажите, как быть в такой ситуации :
Есть 2 таблицы
1. "Группы товаров"
2. "Товары"
Связанные между собой по GROUPID
Как я понимаю нужно загрузить "Группы товаров", а товары к ним по мере обращения. НО... У каждого списка как правило должен быть поиск : edit, где по мере набора фильтруются записи. Получается при выполнении данного функционала(если этот VTV) будут грузиться сразу несколько десятков/сотен чилдов ROOTNODE. При не стабильном соединении с БД это может привести к большому "висяку". Как быть в данной ситуации?

Фоновая загрузка тоже сильная вещь, но надо делать аккуратно: в потоке получать данные, а в контрол их добавлять просить основной поток через PostMessage, поскольку гуй в дельфи сделан так, что грабли лежат где не ждёшь.

1. Зачем тут датасет??? Хочется помедленнее и пообъемнее?
2. Зачем заранее загружать поля записей, которые не видны на экране? Загружай, когда контрол об этом попросит, и кэшируй значения.

Подскажите, как быть в такой ситуации :
Есть 2 таблицы
1. "Группы товаров"
2. "Товары"

Фоновая загрузка тоже сильная вещь, но надо делать аккуратно: в потоке получать данные, а в контрол их добавлять просить основной поток через PostMessage, поскольку гуй в дельфи сделан так, что грабли лежат где не ждёшь.

гуй подлагивает, даже если подгружать в потоке по 1000 записей.

МорскойДесант писал(а) Fri, 27 January 2023 06:34

2. Зачем заранее загружать поля записей, которые не видны на экране? Загружай, когда контрол об этом попросит, и кэшируй значения.

2. тогда при скроле придется отслеживать, достигли ли мы последний(нижний) узел дерева, и фетчить записи, начиная с определенного ID. А если ранее загруженные записи были изменены, то в целом данные в дереве уже будут не актуальны. Проще обновлять мемдатасет и грузить актуальные записи. К тому же, для экспериментов я беру самые экстремальные условия: без фильтрации, огромное кол-во записей - в реальности вряд ли такое встретится

...

Я хочу попробовать поместить два взаимоскрывающих друг друга дерева: первое загружается первыми 1000 записями, второе - невидимое - заполнять в потоке и показать, когда все будет закончено (скрыв при этом первое). Посмотрю, чо будет в визуалке