Out of memory On data fetching

← →
DelphiN! © (2005-12-22 06:36) [0]

DATA.State.SelectSQL.Text := "SELECT * FROM STATE where City_ = "Almaty" and TIME_ >= """+DateToStr(edtDateS.Date)+" "+edtTimeS.Text+""" and TIME_ <= """+DateToStr(edtDatePo.Date)+" "+edtTimePo.Time+""""; DATA.State.Open; DATA.State.First; while not DATA.State.Eof do begin b := false; for i := 0 to strl.Count-1 do if DATA.CmpStr(DATA.State.FieldByName("City_").AsString+":"+DATA.State.FieldByName("Organization_").AsString,strl.Strings[i ]) then b := true; if not b then strl.Add(DATA.State.FieldByName("City_").AsString+":"+DATA.State.FieldByName("Organization_").AsString); DATA.State.Next; end;

После очередного вызова DATA.State.Next вылетает Out of memory. Запрос выводит не более 10 000 записей. Как с этим боротся

← →
Digitman © (2005-12-22 08:22) [1]

> После очередного вызова DATA.State.Next

после какого конкретно "очередного" ?
и сколько элементов в этот момент уже добавлено тобой в стринг-лист ?

← →
DelphiN! © (2005-12-22 08:31) [2]

> [1] Digitman © (22.12.05 08:22)

В стринг листе мало элементов (меньше 10-ти). Вылетает, когда кончается оперативная память(примерно после перехода на 7-ми тысячный элемент). Может можно какнибудь освобождать память? Кстати речь не только об этой ситуации, а вообще о выборке большого колличества записей. Конкретно данный пример можно решить скажем так :

DATA.State.SelectSQL.Text := "SELECT DISTINCT City_,Organization_ FROM STATE where City_ = "Almaty" and TIME_ >= """+DateToStr(edtDateS.Date)+" "+edtTimeS.Text+""" and TIME_ <= """+DateToStr(edtDatePo.Date)+" "+edtTimePo.Time+"""";

так как при данном запросе выводится не большое колличества записей память не кончается, а что делать если под условие подходит большое колличество записей?

← →
DelphiN! © (2005-12-22 08:33) [3]

Кстати забыл указать, что использую ibDataSet

← →
Digitman © (2005-12-22 08:47) [4]

1. лучше отказаться от компонентов IBExpress в пользу пакета FIBPlus

2. если нужно однократно пробежать по НД в направлении от первой записи к последней, то используй TFIBQuery c установленным св-вом Unidirectional = True - однонаправленный НД ощутимо менее ресурсоемкий, нежели НД с двунаправленным курсором

← →
evvcom © (2005-12-22 09:01) [5]

> что делать если под условие подходит большое колличество записей?

1. Вообще-то "количество" всегда писалось с одной "л".
2. Удаление из набора повторов проще действительно возложить на SQL и DISTINCT.
3. Код [0] написан очень неоптимально, что ведет за собой дополнительные, ненужные, холостые запросы на выделение памяти.
4. Не знаю, как там устроен интербейсовский DataLink, а разбираться лень, да и не к чему мне это, но похоже, что при очередном запросе на выделение памяти во время исполнения Next, менеджер не может выделить единого куска требуемого размера. Отсюда и сабж.

← →
DelphiN! © (2005-12-22 09:06) [6]

> [5] evvcom © (22.12.05 09:01)

Понятное дело

> [4] Digitman © (22.12.05 08:47)

А чем так плохи компоненты IbExpress? А как насчет ibDataSet.UniDirectional := true(меня интересует именно 1 проход по НД)?

← →
Johnmen © (2005-12-22 09:12) [7]

Кстати, код крайне неэффективен.

← →
Johnmen © (2005-12-22 09:12) [8]

Удалено модератором

← →
DelphiN! © (2005-12-22 09:16) [9]

> [8] Johnmen © (22.12.05 09:12)

про [0] я ничего и не говорю, просто из старого проекта вырезал, и ради примера привел, а [2] ведь нормальный

← →
Digitman © (2005-12-22 09:20) [10]

> чем так плохи компоненты IbExpress?

Сыроваты они ..
Да и функциональность оставляет желать лучшего ..

FIBPlus на фоне IBExpress выглядит гораздо привлекательней, хотя бы потому что разработчики пакета достаточно оперативно реагируют на выявленные пользователями баги

> как насчет ibDataSet.UniDirectional := true

попробуй ..

в принципе установка этого св-ва у любого из соотв.компонентов любого пакета приводит к одному и тому же результату - вызову соотв. IBAPI-ф-ции с соотв.параметрами

← →
DelphiN! © (2005-12-22 09:28) [11]

> [10] Digitman © (22.12.05 09:20)

Огромное спасибо!

> а [2] ведь нормальный

да тоже ненормальный. Ты про параметры что-нибудь слышал? И какова необходимость генерить динамически SQL?

> [12] evvcom © (22.12.05 09:34)

Слышал, так просто привычней как-то. А чем имеющийся вариант может проигрывать по скорости, тому вырианту где все передается через параметры?

> А чем имеющийся вариант может проигрывать по скорости, тому
> вырианту где все передается через параметры?

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

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

Out of memory On data fetching Найти похожие ветки