[childeroland]

Здравствуйте все. Есть задача, в соответствии с которой табличку .dbf надо отфильтровать по полю с типом date. Табличка клипперовская, файл индекса имеет расширение .ntx. Для примера я создавал индекс в ручную по нужному мне полю и делал по нему фильтр в Apollo Table, выборка данных проходила шустро, несмотря на то, что в таблице более миллиона записей.
Проблема в том, что индекс, который мне на самом деле нужно использовать создаётся автоматически другой программой при добавлении записей (вообще говоря, в конце дня, но это не важно) и строится он не совсем так, как делал его я, а именно, в качестве индексного выражения используется такая вот бяка:

Код:

DTOS(sysdate)

, где sysdate - поле типа date.
Т.е., на сколько я понимаю, дата преобразовывается в строку в формате yyyymmdd, без разделителей. В результате мой код с фильтром, который выглядит вот так:

Код:

...
ApolloTable1->filtered = false;
ApolloTable1->filter = "sysdate = CTOD('01.01.2013')"; //Дата для примера, в программе она формируется динамически
ApollTable1->filter = true;
ApolloTable1->open();

выполняется, фильтрует даты, но возвращает результат очень медленно, такое впечатление, что он не использует индексный файл. Пробывал подкидывать дату в формате yyyymmdd в виде строки, не помогает. Кто сталкивался с такой проблемой? Кто что может подсказать? Буду очень благодарен.

[Mrak]

Попробуй SQL запросы.
Аналогичная строка твоему фильтру

Код:

query1.sql.text:='SELECT * FROM apolltable1 WHERE sysdate = CTOD('01.01.2013')';
query1.open;

[childeroland]

Сообщение от Mrak

Попробуй SQL запросы.
Аналогичная строка твоему фильтру

Код:

query1.sql.text:='SELECT * FROM apolltable1 WHERE sysdate = CTOD('01.01.2013')';
query1.open;

Надо было приписку сделать "вариант с SQL не предлагать" =)... Если серьёзно, то у меня локальная таблица на почти два миллиона записей, SQL-запрос выполняется по ней очень медленно, тем более, что из отобранных записей мне надо сделать ещё одну фильтрацию. SQL первое, о чём я подумал, но когда программы выполняется более 40 минут, я думаю, это не приемлемо. Если использовать Table вместо Query, то выборка данных не превышает минуты, а зачастую намного меньше, правда (что, собственно, и послужило поводом обращения на форум) только в том случае, когда я использую свой собственный индекс, где нет преобразования даты в строку.

[childeroland]

Сообщение от Mrak

Попробуй SQL запросы.
Аналогичная строка твоему фильтру

Код:

query1.sql.text:='SELECT * FROM apolltable1 WHERE sysdate = CTOD('01.01.2013')';
query1.open;

И, кстати, в случае с ApolloQuery вполне можно обойтись запросом вида:

Код:

select * from SomeTable where SomeDateField = #01.01.2013#

Это проверено, так как изначально делал именно на Query. Вариант с ctod('01.01.2013'), правда, не пробовал.

[Mrak]

ну, грубо говоря, table тоже шлет SELECT * FROM че-то
а потом мы с этим контейнером работаем

может быть драйвера?

p/s/ глянь ЛС


заинтересовало в своей базе))
взял adotable + удаленный mysql + лог на 100к записей + таймер. время открытия - около 1мин 30сек
все то же самое, но через adoquery (select * from log). время открытия - около 1мин 10сек

[childeroland]

Сообщение от Mrak

ну, грубо говоря, table тоже шлет SELECT * FROM че-то
а потом мы с этим контейнером работаем

может быть драйвера?

p/s/ глянь ЛС


заинтересовало в своей базе))
взял adotable + удаленный mysql + лог на 100к записей + таймер. время открытия - около 1мин 30сек
все то же самое, но через adoquery (select * from log). время открытия - около 1мин 10сек

Видимо как раз дело в том, что у тебя mysql обрабатывает запросы, это логично, что sql в такой связке будет быстрее, но у меня, я уже вроде говорил, таблица лежит локально, недалеко от исполняемого файла, никаких субд в принципе нет, тупо обращаюсь к таблице .dbf и вот через query капец как тормозит.
p.s. в принципе, я уже реализовал код через ApolloTable, работает шустро, хоть, может, и через задницу, но всё-таки разобраться в вопросе не мешало бы, так что жду ещё предложений