iBase.ru Forum

Подскажите, можно ли как-то включить Unidirectional в IBQuery, чтоб потом в DBGrid нормально все отображалось. У меня при открытии таблицы с установленным параметром и после прокрутки грида вниз, а потом вверх отображается полная ахинея.

Удивительно даже. С чего бы это, интересно?

спасибо, проверил не помогло, может еще есть варианты?

что значит "ахинея"? какая версия IBX? действительно ли нужно включать unidirectional в true?

версия 7.08
необходимость есть в связи с настоятельными рекомендациями перевести параметр в true при проблеме "out of memory".
ахинея выражаеться в дубляже строк при прокрутке dbgrid, если информация не помещается в один экран.

Голубчик, а встать в OI на это слово и F1 нажать не пробовал? А то, знаешь ли, очень забавно выглядит - я включил свойство, приводящее к невозможности обратного скроллирования, так вот, какая-то ахинея получается - невозможно обратно скроллировать!

вот эмуляция проблемы, код и база. архив небольшой 400kB, посмотрите.
ftp://1:1@213.186.210.150/test.rar

и все же какое решение?

Элементарное - ограничивать выборки через кляузу where, а не тягать на клиента всю базу пока он не треснет.

выборки минимальны от 5 до 10, просто за сутки их очень много и приходит финиш по какой-то причине(out of memory у клиента хотя свободной памяти просто завались) вся причина в tibquery то ли он не видит что оперативки просто завались то ли черт его знает что за бага в нем, в инете масса топиков на эту тему. и решение всегда предлагается либо unifirectional=true либо вообще уйти с этого компонента например на tibsql на котором как народ проверил эта проблема сразу исчезает. но уйти нет возможности прога нереально большая, переписать год уйдет. вот и ищу решение, вразумительного ответа нет нигде к сожалению.

Я бы советовал таки меньше слушать разный трёп по инету, а больше думать головом. TIBQuery кеширует всё, что начитал, именно для того, чтобы позволить обратный скроллинг. До момента Close, когда всё и освобождает. А UniDirectional как раз и значит - ОдноНаправленный. Режим используется главным образом в скрытых от ползателя циклах типа "пробежаться по выборке от начала до конца и всё проапдейтить по хитрым условиям или залить в другую таблицу, типа датапампа" или когда TIBQuery используется в качестве источника данных для другого кеширующего компонента, например TClientDataSet - механизмы MIDAS устроены так, что при открытии сами открывают источник, вытягивают всё в ClientDataSet и источник закрывают, то есть при UniDirectional False в момент закачки получится никому не нужный двойной расход памяти. Если же у тебя курсоры короткие, и не открываются сотнями тыщ без закрытия, то ты не там ищешь. У тебя утечка памяти, в твоём собственном коде, а не перерасход. И out of memory у клиента быть не может, если у него этой мемори завались.

на котором как народ проверил эта проблема сразу исчезает.

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

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

я так понимаю что если есть утечки памяти в коде в компоненте и так далее неважно где, мы приходим к тому что память сьедаеться и получаем out of memory. но ЕСТЬ свободная память ЕСТЬ ну как же еще это написать, ну простым диспетчером задач смотрю и вижу 1.5Gb свободной. или я как-то в проге должен указать что вот бери память сколько те надо не стесняйся. я лично подозреваю что дело даже не в количестве выбранных записей 100 или 100000, а в том что кеш не очищается в принципе, и как бы я не пытался минимизировать выборку в течении какого-то времени опять будет out of memory.

откуда такая уверенность, что память сжирает IBQuery? Вопрос ведь именно в этом.
Почему-то у тучи людей, которые работают с IBX таких утечек памяти не наблюдается. Вы для себя хотя бы тестовый пример можете сделать, чтобы убедиться в источнике проблемы?

kdv писал(а):Почему-то у тучи людей, которые работают с IBX таких утечек памяти не наблюдается.

+1

victor3000 писал(а):я так понимаю что если есть утечки памяти в коде в компоненте и так далее неважно где, мы приходим к тому что память сьедаеться и получаем out of memory. но ЕСТЬ свободная память ЕСТЬ ну как же еще это написать, ну простым диспетчером задач смотрю и вижу 1.5Gb свободной. или я как-то в проге должен указать что вот бери память сколько те надо не стесняйся. я лично подозреваю что дело даже не в количестве выбранных записей 100 или 100000, а в том что кеш не очищается в принципе, и как бы я не пытался минимизировать выборку в течении какого-то времени опять будет out of memory.

Есть память физическая, а есть виртуальная. Нехватает второй.
Кто-то не умеет пользоваться VirtualAlloc \ VirtualFree

Под специфические ресурсы системы, типа семафоров, рукояток и прочего, выделяется тоже ограниченная память, не связанная с твоими гигабайтами.
Твой пример (уже?) недоступен.

ок. я запутался совсем. есть какая-то память кроме физической она заканчивается. чесно говоря для меня это новость. я не умею пользоваться какими-то алоками и фри чего-то там(чесно говоря не понимаю зачем это нужно). ладно признаю я полный идиот так будьте же так любезны не говорить загадками а скажите конкретно что нужно сделать. а то фигня получается память физическая есть, а файрберд работает с какой-то другой памятью, не понятно лично для меня причине.
я абсолютно не против пускай он использует физическую и не пишет мне
out of memory при 1,5gb свободного ОЗУ, ах да еще 2Gb файл подкачки существует тоже кстати пустует.

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

да что вы конечно не расчитываю, просто пофлудить пришел как и вы.