Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Очередной глюк FireBird или это можно обойти? [D7, FireBird 1.0.3]

Andrio © (2003-05-17 13:43:00)
Имеется БД из 27 таблиц, в которой (естественно)активно используются триггеры и ComputedBy поля. Этих ComputedBy полей довольнно много...
В процессе заполнения таблицы с ComputedBy полями суммы, которые должны вичислятся сразу не показываются. (Для вставки записей используется IBTable Insert-Post).
Я попробовал - IBTransaction.CommitRetaining - результат нулевой.
Затем вызвал для нужной таблицы методы: ApplyUpdates,Refresh.
После этого стали пропадать некоторые записи из таблицы... Т.е. DBGrid не показывает часть записей, причем ни какой закономерности в выборе непоказываемых записей я не нашел :((
После повторного открытия НД записей показывается побольше (хотя и опять не все). После "ApplyUpdates,Refresh", их количество вновь сокращается.
Та же самая картина возникла при просмотре таблицы в IBExpert."

Мне так кажется что FireBird-у не хватает каких то ресурсов для их показа.

1. Помогите решить проблемму показа всехзаписей в таблице.
2. Каким способом лучше сохранять данные в БД, используя IBTable исползуя не Commit, а CommitRetaining?

Zacho (2003-05-17 19:05:00) [1]

> Sergey Masloff (17.05.03 18:33)

У меня тоже прецедентов не было, даже на 5.x, но есть четкое ощушение, что где-то я читал или слышал, причем не однократно, о таких проблемах в FB. Впрочем, может ложная память :-)

Sergey Masloff (2003-05-17 18:33:00) [2]
Zacho ©
Да, все правильно. Про 5.6 там речь в посте на который Ded отвечал. Кроме того, у меня Commit Retaining на read транзакции может поэтому не наступаю на эти грабли. Но повторю - прецедентов не было.

Sergey Masloff (2003-05-17 18:29:00) [3]
Zacho ©
>В каком билде FB или Ya исправлено ?
Точно не скажу, расскажу примерно. Про проблему с Commit Retaining в 5.x я знал и избегал использовать. Потом уже перейдя на FB еще во времена RC2 я прочитал на IBPhoenix в какой-то статье что-то типа: наконец-то решена проблема с Commit Retaining пользуйтесь смело. Я тут же воспользовался и проблем не испытал. Причем база для тестирования хорошая - у меня программа несколько сотен установок и есть протоколирование возникающих ошибок, протоколы я получаю и анализирую постоянно. с ...To many savepoints проблем не возникало. FB 1.0 и 1.2

P.S. А что Ded писал по этому поводу? Мне на глаза не попадалось. Хотя архив есть сейчас посмотрю.

Zacho (2003-05-17 17:55:00) [4]

> Sergey Masloff (17.05.03 17:47)

А можно подробнее ? В каком билде FB или Ya исправлено ? А то я похоже пропустил это, еще недавно кажется на epsylon.public.interbase было весьма ехидное письмо Ded"а про эту проблему, а потом вроде ничего не видел.

Sergey Masloff (2003-05-17 17:47:00) [5]
Zacho ©
>Лучше не использовать CommitRetaining - есть риск напоротся на "Too many savepoints.. "
AFAIK эта проблема осталась в прошлом.

Zacho (2003-05-17 17:36:00) [6]
1. Если CachedUpdates:=true и Filtered:=true - то это баг IBX, к FB никакого отношения не имеет. Лучше не пользуйся CachedUpdates с включенной фильтрацией, еще и не такое может быть. А если фильтрация выключена - тоже скорее всего баг CachedUpdates.

> Та же самая картина возникла при просмотре таблицы в IBExpert.

А какой уровень изоляции транзакций установлен в IBExpert ?
2. Странный вопрос. Нифига не понятно. Но кое-что могу сказать:
Лучше не пользоваться IBTable. Есть IBDataSet - лучше пользоваться им. Лучше не использовать CommitRetaining - есть риск напоротся на "Too many savepoints.. " и даже на разрушение БД после " ... Cannot continue after bugcheck".
P.S. - есть замечательный сайт по IB - http://www.ibase.ruСоветую внимательно изучить его, особенн статьи в разделе "Для разработчика"

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »