Locate в InterBase

← →
ivb2001 (2004-02-11 15:15) [0]

Please, почему жутко медленно работает TibQuery.Locate c IBase? Всего-то 3к записей. Пришлось написать свой поиск, но этоже средневековье! За что боролись!!!

← →
Vlad (2004-02-11 15:19) [1]

> ivb2001 © (11.02.04 15:15)

Посмотри реализацию - там полный перебор по всем записям. Чего ты хочешь ?
Кстати, обещают что поиск будет быстрым если поле в таблице проиндексировано.

← →
HSolo (2004-02-11 15:20) [2]

Лично я борюсь за ограничение выборки :))
А что делается с этими 3к записей? Показ в гриде + поиск на клиенте?

← →
VLAD-MAL (2004-02-11 15:20) [3]

Ну, так создай свой, отдельный TibQuery с

Select * where (супер-пупер условия поиска)

и если план запроса будет удачный, все будет OK!

Еще варианты: может, у тебя много длинных Varchar - полей. Так вот, они только хранятся компактно, а по сети все пустышки перегоняются. Переходи на FireBird 1.5

← →
Johnmen (2004-02-11 15:32) [4]

После TibQuery.FetchAll искать должно быстро.
На CELERON1000 SDRAM100 на 3000 записях простое сканирование с проверкой (результат положителен на последней записи) время ~0.4 сек.

← →
Vlad (2004-02-11 15:36) [5]

Вот строчка из хелпа:

Locate uses the fastest possible method to locate matching records. If the search fields in KeyFields are indexed and the index is compatible with the specified search options, Locate uses the index. Otherwise Locate creates a filter for the search.

Так что можно воспользоваться советом и просто проиндексировать поле.

← →
VLAD-MAL (2004-02-11 15:37) [6]

Может, у него в Locate поиск по 25 ключам...

← →
Anatoly Podgoretsky (2004-02-11 15:40) [7]

Какие индексы у возращенного запроса, Locate работает на клиенте, последовательный перебор, но на трех тысячах практически мгновенно, конечно сначала надо получить все записи на клиента.

← →
Vlad (2004-02-11 15:47) [8]

> Anatoly Podgoretsky © (11.02.04 15:40) [7]

Получать все записи на клиента м.б. накладной процедурой, если их много. А последовательный фетч с сервера теоретически может ускорить если по этому полю есть индекс. Иначе, как по-другому объяснить строчки из справки ?

← →
Anatoly Podgoretsky (2004-02-11 16:57) [9]

Еще раз, откуда индекс у запроса, конечно он бы ускорил.

← →
Соловьев (2004-02-11 17:15) [10]

Я делаю сначала запрос к БД(select ... where ), и если запись есть , беру ключевое поле и только тогда иду Locate, и еще желательно отключить AfterScroll на этом НД.

← →
Sandman25 (2004-02-11 17:20) [11]

[10] + получается, что кроме AfterScroll желательно вызвать и DisableControls. Может замедление из-за перерисовки грида?

← →
Deniz (2004-02-12 07:09) [12]

Если select ... order by field1 а locate по field2, то индекс врядли будет использоваться, даже если он есть :(

← →
ivb2001 (2004-01-23 13:28) [13]

Спасибо всем, кто отозвался. Вкратце, ситуация такова:
Таблица (список заказов):
CREATE TABLE ZAKLIST (ZAKLIST_REFER INTEGER NOT NULL, NOMER VARCHAR(10), TYPE SMALLINT, ZAKAZDATE DATE, READYDATE DATE, FACTDATE DATE, NOCOMPLECT SMALLINT, OUTDATE DATE, ZAKAZOUT SMALLINT, WHYNOT VARCHAR(50), PRIMECH VARCHAR(50), DELETED SMALLINT, EDITED SMALLINT, ZAKAZRETURN SMALLINT, WHYRETURN VARCHAR(50), PRIMARY KEY (ZAKLIST_REFER));
Индекс:
CREATE UNIQUE INDEX ZAKLIST_INOMERDATA ON ZAKLIST(NOMER, ZAKAZDATE);

Номер заказа может повторяться, но в разные дни. Сортировка либо по номеру либо по дате. Клиент вводит номер и надо просто спозиционировать DBGrid на первый заказ с таким номером.
С Locate локальный расклад работает быстрее сетевого, но все-равно это "смерть фашизму". Свой поиск (обычный, делением на 2) летает, как из пушки.

>to Sandman25 [11] DsableControls не помогает.
>to Vlad-Mal[3] А как потом установить TibQuery Grid-овый на запись найденую в TibQuery поисковом?
> Соловьеву [10] AfterScroll не пробовал. Спасибо.
> Johnmen [4] Тоже спасибо - проверю.

← →
Johnmen (2004-01-23 13:43) [14]

>ivb2001 © (23.01.04 13:28) [13]

Немного не в тему - как удалось создать уникальный индекс с использованием поля (ZAKAZDATE), для которого м.б. NULL ?

← →
Vlad (2004-02-12 15:04) [15]

Я тут проверил, Locate в IBQuery работает одинаково что по ключевым что по неключевым полям, индексы никак не влияют.
В справке явный обман.
Так что смысла в [10] скорее всего нету.
Так что вариант один - фетчить все записи на клиента, как сказал Johnmen © (11.02.04 15:32) [4]

← →
Соловьев (2004-02-12 15:26) [16]

2 Vlad
ну и причем AfterScroll к индексу?
Я про то что когда используют перемещение по записям, то желательно убрать обработку события AfterScroll

← →
Vlad (2004-02-12 16:23) [17]

> Соловьев © (12.02.04 15:26) [16]

Я про то что сначала делать автономный select, а потом Locate - особого смысла не вижу.
А отключение AfterScroll (если там что-то есть) естественно поможет, но опять же не всегда бездумно можно его отключать, сам понимаешь.

← →
Соловьев (2004-02-12 16:24) [18]

смысл в том что если нет записи ты не будешь тянуть все записи при Locate клиенту. а это согласись полезно.

← →
Vlad (2004-02-12 16:36) [19]

> Соловьев © (12.02.04 16:24) [18]

Если сделать FetchAll сразу после открытия НД, то локейты будут пулять со свистом, вчера проверял на 300 тыс записей - доля секунды.

← →
Соловьев (2004-02-12 17:00) [20]

Это ты себе можешь пару раз 300 тыс скопировать в ОП, а если у клиента не ахти с памятью? или сеть не очень? то что тогда?

← →
ivb2001 (2004-02-13 13:49) [21]

Еще раз всем спасибо!
Позвольте считать собрание закрытым.

P.S.
to Johnmen © (23.01.04 13:43) [14] Поле ZAKAZDATE не предназначено для ввода. Оно заполняется автоматом при создании новой записи текущей системной датой и потому пустым быть не может по определению. Конечно надо было подстраховаться, но, сам понимаешь, - то руки не доходят, то ноги не доносят...

Locate в InterBase Найти похожие ветки