iBase.ru Forum

Привет всем!
Замучал AV в gds32.dll...
При старте формы делаются запросы к базе (загрузка настроек юзера, сохранение текущего запроса, проверка прав юзера на таблицу и поля таблицы). При закрытии формы - сохраняются настройки юзера.
Проблема такая - после нескольких открытий/закрытий - AV in gds32.dll
Предположительно, происходит это после отработки загрузки настроек, т.е. после него ЛЮБОЙ запрос (да хоть внутренний IBO-шный) приводит к AV и последующему зависанию...
Кстати, AV может и не выводиться юзеру (в Дэлфи - всегда выводится), а сразу виснет...
Причём не помогает даже Halt в случае exception'а

Повторяю - конкретного места сбоя я не нашёл, AV может возникнуть, а может и нет...

Запросы в общем-то простые... типа 'select * from table' и 'select fields from table where simple_conditions'...
но поля, по которым производится поиск при загрузке/сохранении настроек непроиндексированы (это важно?)

Что это, о великие гуру ИБ?

Сервер: Yaffil 1.3.0.885 Classic
Компоненты доступа к IB: IBO 4.2Ie под Delphi 7

Если что-то ещё понадобится - спрашивайте, отвечу (начиная с 26.01.2006, а то уже раб. день у меня закончился)

А версия gds32.dll версии сервера точно соответствует? Или борландовый от IB5.0, что встал вместе с Delphi?

Merlin

А версия gds32.dll версии сервера точно соответствует? Или борландовый от IB5.0, что встал вместе с Delphi?

Точно соответствует. Родная - билд 885, как у сервера.

Проверил на билде 889 - то же самое
Может, это IBO?

Лично я встречал AV в gds32 только при вызове нескольких исполняемых SP с разным количеством выходных параметров в одной транзакции в борландовом клиенте. В FB пофиксили ещё в 1, так что в Дятле по идее тоже не должно быть. Если получится сделать воспроизводимый тест, надо обратиться к Олегу, а по стуку в подвале он вряд ли что сможет сделать.

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

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

А это что за зверь?
Коннект один, транзакции у IBO автоматические. Кстати, Read Commited у транзакции, если что...
Т.е. грубо говоря, я просто делаю Connect и всё.

Если вернуться к нашим баранам, то с большой вероятностью AV вылазит после сохранения (!) настроек, а не восстановления, как я думал. Т.е. сохранение срабатывает, восстановление тоже, а вот любой следующий - AV
Сохранение и восстановление делается запросом select поля from table where условия... С той лишь разницей, что идёт чтение+сохранение записи и просто чтение соответственно...
Сейчас переделываю сохранение в процедуру, надеюсь поможет...

Хм...
Уж не знаю, в чём дело, но склоняюсь к тому, что в компонентах IBO...
Переделал запрос в хранимую процедуру - AV исчез...
хотя процедуру выполняю через те же IBO...
мистика, прям

В принципе, вопрос исчерпан, но если кто-нибудь когда-нибудь узнает 100%-но, из-за чего всё-таки мог быть тот AV, милости прошу в пм ради интереса...