Скачать: CL | DM;

Ошибочный статус UpdateKind в наследнике от TStoredProc.   Найти похожие ветки 

← →
Erik1 ©   (2005-02-21 16:55) [0]

У нас в проекте используется наследник от TStoredProc, все система использует BDE + ORACLE. Недавно вслыл диковеный баг, что обидно непонятно время его появления и причины. В наследнике определен обрабочик DoUpdateRecord, в нем происходит физическое обновление записей на сервере через вызовы процедур. Обнаружил, что при входе в DoUpdateRecord неправильно определен UpdateKind в ukInsert. Хотя реальное состояние ukModify! Такое поведение возникает устойчиво если по записи происходит двойное редактирование. Тоесть Edit Post Edit Post. При иследовании выяснилось, что неправильный статус приходит из function TBDEDataSet.CachedUpdateCallBack(CBInfo: Pointer): CBRType; в этой процедуре есть вызов UpdateKind := TUpdateKind(ord(FUpdateCBBuf.eDelayUpdOpType)-1); так eDelayUpdOpType уже определяется неправильно! Мы в наследнике никак неможем влиять на UpdateKind, но при выше указаных действиях он портится. Разумеется, что используется CachedUpdates. Все необходимые разяснения предоставлю. Кто дерзнет покопатся в сложном вопросе. Вопрос где дальше смотреть, куда копать???

---

← →
Erik1 ©   (2005-02-22 11:22) [1]

Что, даже где смотреть никто незнает?!

---

← →
Erik1 ©   (2005-02-22 13:41) [2]

Все как всегда, никто незнает. Для справки: после вставки записи ее статус неменяется. Вот заголовок записи PRecInfo(BufPtr + FRecInfoOfs).UpdateStatus BufPtr вобщем случае равен ActiveBuffer. Так, что надо в ручную менять статус.

---

← →
Val ©   (2005-02-22 17:35) [3]

И не говорите. Ламерье собралось, правда? Нет чтобы кинуть все на..и покопаться хорошенько в вашей проблеме. Что сюда ходить?

---

← →
Erik1 ©   (2005-02-23 11:33) [4]

Правда не правда, но на сложные вопросы я никогда ответов неполучал. На других сайтах тоже неполучал, возможно, что в инет ходить нестоит.

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.46 MB
Время: -0.977 c