Форум: "Базы";
Текущий архив: 2003.06.05;
Скачать: [xml.tar.bz2];
ВнизОчередной глюк FireBird или это можно обойти? Найти похожие ветки
← →
Andrio (2003-05-17 13:43) [0]Имеется БД из 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 17:36) [1]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 Советую внимательно изучить его, особенн статьи в разделе "Для разработчика"
← →
Sergey Masloff (2003-05-17 17:47) [2]Zacho ©
>Лучше не использовать CommitRetaining - есть риск напоротся на "Too many savepoints.. "
AFAIK эта проблема осталась в прошлом.
← →
Zacho (2003-05-17 17:55) [3]
> Sergey Masloff (17.05.03 17:47)
А можно подробнее ? В каком билде FB или Ya исправлено ? А то я похоже пропустил это, еще недавно кажется на epsylon.public.interbase было весьма ехидное письмо Ded"а про эту проблему, а потом вроде ничего не видел.
← →
Sergey Masloff (2003-05-17 18:29) [4]Zacho ©
>В каком билде FB или Ya исправлено ?
Точно не скажу, расскажу примерно. Про проблему с Commit Retaining в 5.x я знал и избегал использовать. Потом уже перейдя на FB еще во времена RC2 я прочитал на IBPhoenix в какой-то статье что-то типа: наконец-то решена проблема с Commit Retaining пользуйтесь смело. Я тут же воспользовался и проблем не испытал. Причем база для тестирования хорошая - у меня программа несколько сотен установок и есть протоколирование возникающих ошибок, протоколы я получаю и анализирую постоянно. с ...To many savepoints проблем не возникало. FB 1.0 и 1.2
P.S. А что Ded писал по этому поводу? Мне на глаза не попадалось. Хотя архив есть сейчас посмотрю.
← →
Sergey Masloff (2003-05-17 18:33) [5]Zacho ©
Да, все правильно. Про 5.6 там речь в посте на который Ded отвечал. Кроме того, у меня Commit Retaining на read транзакции может поэтому не наступаю на эти грабли. Но повторю - прецедентов не было.
← →
Zacho (2003-05-17 19:05) [6]
> Sergey Masloff (17.05.03 18:33)
У меня тоже прецедентов не было, даже на 5.x, но есть четкое ощушение, что где-то я читал или слышал, причем не однократно, о таких проблемах в FB. Впрочем, может ложная память :-)
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.06.05;
Скачать: [xml.tar.bz2];
Память: 0.46 MB
Время: 0.009 c