Текущий архив: 2005.03.27;
Скачать: 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 вся ветка
Текущий архив: 2005.03.27;
Скачать: CL | DM;
Память: 0.47 MB
Время: 0.039 c
