Траблы с запросом

← →
}|{yk © (2005-01-20 13:09) [0]

Такой вот запрос
SELECT APP_LOG_TIME, APP_LOG_OPERATION, APP_LOG_OLD_VALUE, APP_LOG_NEW_VALUE, DML_CODE, APP_LOG_ID, APP_LOG_TABLE, STATUS, REASON FROM APP_LOG where STATUS="not sended" or STATUS=:inSTATUS1 or STATUS=:inSTATUS2 or STATUS=:inSTATUS3 order by APP_LOG_TIME
во первых, при исполнении хавает 60 Мб на таблице из 9000 записей. Но это ладно. Но при прохождении по таблице с начала до конца на 6 тыс записей сообщает Out of memory. Хотя прога занимает 35 Мб памяти, и свободной памяти много. Что сделано неправильно? FB 1.5.2

← →
Соловьев © (2005-01-20 13:14) [1]

индекс есть по APP_LOG_TIME? STATUS?
Попробуй
...
where STATUS in("not sended", :inSTATUS1, :inSTATUS2, :inSTATUS3)
...

← →
}|{yk © (2005-01-20 13:26) [2]

Смысл индекса в поле, где может быть только 4 варианта?

← →
Соловьев © (2005-01-20 13:27) [3]

тогда не надо

← →
Соловьев © (2005-01-20 13:28) [4]

а какой тогда смысл проверки? 8)

← →
Danilka © (2005-01-20 13:39) [5]

> во первых, при исполнении хавает 60 Мб на таблице из 9000
> записей. Но это ладно. Но при прохождении по таблице с начала
> до конца на 6 тыс записей сообщает Out of memory. Хотя прога
> занимает 35 Мб памяти, и свободной памяти много. Что сделано
> неправильно? FB 1.5.2

Если запустить запрос в ИБЭксперте и пролистать результат выполнения до конца, то-же самое происходит?
Сдается мне что дело не в запросе и не в индексах (9к записей без всяких индексов такой запрос шустро отработает), а в том, что ты делаешь "при прохождении по таблице с начала до конца".

← →
Desdechado © (2005-01-20 14:16) [6]

у тебя случайно блобы не достаются?
это не блобы ли: APP_LOG_OLD_VALUE, APP_LOG_NEW_VALUE
Out of memory - это ClientDataSet может говорить, если фетчишь много и с блобами (поставь fetchblobondemand)

← →
}|{yk © (2005-01-20 14:17) [7]

При выполнении в IBExpert запрос так же хавает 60 Мб памяти сервера. Но отфетчить записи можно.

← →
Johnmen © (2005-01-20 14:42) [8]

>}|{yk ©

Какой размер записи ?

← →
}|{yk © (2005-01-20 14:45) [9]

Можно поставить UniDirectional := True. Но случился какой-то непонятный глюк и 20 записей в нужный файл так и не попало

← →
Ega23 © (2005-01-20 14:48) [10]

2 }|{yk © (20.01.05 13:09)
Оффтоп.
Я бы на твоём месте поле STATUS или целочисленным сделал, или вообще в отдельную таблицу бы вынес. Хранить строки как-то...

← →
}|{yk © (2005-01-20 15:07) [11]

Пожирание 60 Мб было связано с... order by APP_LOG_TIME. Поставил order by LOG_ID - FB на запрос отнимает всего 5 Мб!

← →
Vlad © (2005-01-20 15:10) [12]

> }|{yk © (20.01.05 15:07) [11]

Сделай индекс по APP_LOG_TIME

В продолжение... Если поставить UniDirectional в true то все работает быстро. Но! Первые двадцать записей с непонятных мне причин имебт такие индексы: 1,20,1,20,1,20...22,23,24 и дальше нормально! Если же UniDirectional = false, то на 6 тысяче Out of memory

Вобщем, решил эту проблему следующим образом. Перед проходом по датасету устанавливаю dataset грида в nil. После окончания - восстанавливаю обратно. Работает, причем довольно быстро

а грид тогда зачем? а если я в гриде буду листать, вылетит?

Жук, поясни для тупых: где тормоз-то: на выполнении запроса или на сканировании ?
И зачем вообще сканировать ?
Если не секрет, конечно.

Траблы с запросом Найти похожие ветки