iBase.ru Forum

Вопрос мож и детский, но FIB купил только вот-вот, ещё не со всем разобрался.. а сроки жмут.. вобщем все как у всех.. Вопрос такой: если установлено свойство CachedUpdates в True (это необходимо для обработки события LostConnect) и использованы две транзакции одна длинная для чтения и другая короткая для модификаций (как и рекомендудеться в доке для уменьшения количества блокировок и пр. геморроя) - то не отображаются изменения данных, т.е. в гриде значение ячейки "Мля" меняю на "Мляха", перехожу на следующую запись и лицезрею "Мля", хотя в базе уже "Мляха" потому как AutoCommit=True. Если использую одну и ту же пишущую транзакцию и для чтения и для записи - все работает и это понятно, но в этом случае получается, что я не могу использовать всех прелестей так заботливо предоставленных разработчиками FIB. Параметры читающей транзакции:read, nowait, rec_version, read_committed; пишущей: write, nowait, concurrency, read_committed. Подскажите, что тут не так, а ?

Мдя-а-а, не густо... Вобщем пока вышел из ситуации путём установки AutoCommit=False. Не совсем то, что хотелось бы, но в моей ситуации вполне приемлемое решение.

у тебя с refreshSQL что-то не то. То есть, после модификации запись считывается не то или вообще ничего не считывается. Или ты запутался в транзакциях или их параметрах.

Кстати, не совсем понятно, зачем тебе CachedUpdates для обработки LostConnect. Если для Briefcase model, то есть для возможности работы после отключения коннекта, то тут лучше пользоваться ClientDataSet.
М.б. я отстал от современных технологий, но после именно обрыва коннекта держать данные закэшированными в обычном датасете смысла мало.