Текущий архив: 2003.05.15;
Скачать: CL | DM;
Вниз
CachedUpdates, ApplyUpdates & exceptions Найти похожие ветки
← →
Alexis (2003-04-22 18:45) [0]Народ, помогите!!! я просто в трансе...
есть стандартный проект: database (подключенная к oracle), на ней query (cachedupdates=TRUE + updateObject), на ней datasource и к нему dbgrid.
вбиваю в грид 5 записей в режиме кэша с ID = 1,2,1,4,5. сохраняю.
(кусок просто взят из хелпа)
db.StartTransaction;
try
query.ApplyUpdates;
db.Commit;
except
db.Rollback;
raise;
end;
query.CommitUpdates;
при сохранении в базу идут insert-ы для записей 1 и 2 после чего, понятно, вылетает исключение (нарушение ограничения целостности). в БД происходит откат. удаляю проблеммную запись. В гриде остаются: 1,2,4,5. Делаю опять сохранить. И что получаю на выходе??? получаю insert для записей 4 и 5. а где 1 и 2 ???
как я понимаю Дельфи решила, что 1 и 2 уже сохранены успешно!! а на транзакцию ей наплевать. как решить проблему?
заранее спасибо.
← →
Johnmen © (2003-04-22 23:25) [1]Логика явления соответствует принципам работы с кешированным НД.
Дело в том, что после первого ApplyUpdates изменения в буфере для 1 и 2 фиксируются и этот буфер изменений (дельт) очищается.
При повторном ApplyUpdates для 1 и 2 ничего не делается, т.к. их буфер дельт пуст...
Пересмотри несколько логику принятия изменений.
← →
Alexis (2003-04-23 11:17) [2]Спасибо, Johnmen...
дело в том, что я расчитывал на технологию двухфазного сохранения, которая так ярко описана в самом хелпе и вроде бы годами работало правильно.. если только я не заблуждаюсь.
вот кусок из хелпа, раздел "Applying updates for master/detail tables"
Database1.StartTransaction;
try
Master.ApplyUpdates;
Detail.ApplyUpdates;
Database1.Commit;
except
Database1.Rollback;
raise;
end;
Master.CommitUpdates;
Detail.CommitUpdates;
If an exception is raised during the call to Master.ApplyUpdates, it is handled like the single dataset case previously described. Suppose, however, that the call to Master.ApplyUpdates succeeds, and the subsequent call to Detail.ApplyUpdates fails. In this case, the changes are already applied to the master table. Because all data is updated inside a database transaction, however, even the changes to the master table are rolled back when Database1.Rollback is called in the except block. Furthermore, UpdatesMaster.CommitUpdates is not called because the exception which is re-raised causes that code to be skipped, so the cache is also left in the state it was before the attempt to update.
примерный смысл в том, что пока не выполнена функция CommitUpdates изменения в кэше не убиваются и компонент остается в том же состоянии, что и был перед началом операции. Поэтому при возникновении исключения на этапе сохранения дитэйлов мастер все равно остается не сохраненным и дитэйлы тоже (это по хелпу), а на деле оказывается иначе...
может быть я чего-то не то делаю? или еще надо что-то прописать? или это работает только на парадоксе?
← →
Johnmen © (2003-04-23 15:59) [3]>Alexis
А какая БД и компоненты доступа ?
А то вот нахлынули воспоминания о работе с кешированными НД с исп-ем BDE...Не все там было гладко, не все совпадало с хелпом, были баги...:)
← →
Alexis (2003-04-25 12:35) [4]БД - Oracle
компоненты доступа - обычные DB компоненты
компонента запроса - TRxQuery
самое интересное то, что я сделал тестовый проект, как описал выше и все по хелпу. а работает черт знает как... и корни проблемы уходят в bde.pas, исходников которого нету. кэш - это привилегия самого бде. может проблема в нем? версия бде у меня 5.01
в общем тоска... придется наверное садиться и переписывать сохранение. :(
Страницы: 1 вся ветка
Текущий архив: 2003.05.15;
Скачать: CL | DM;
Память: 0.48 MB
Время: 0.013 c
