AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.04.2006, 17:29   #1  
Seer_imported is offline
Seer_imported
Участник
 
75 / 10 (1) +
Регистрация: 08.12.2005
Всем привет.

Наткнулись на очень интересную ситуацию - попахивает ошибкой ядра при реализации механизма оптимистической конкуренции - не полностью откатывается транзакция.
Сразу объясню, как ее смоделировать. В прилагаемом фобе - 2 таблицы. В таблице Test Validate нужно создать 2 записи, заполнив Entry No., Code1 и Decimal1. После этого, в любой записи изменить поле Code1 и, никуда из него не переходя, открыть второго клиента Навижн. В этом клиенте нужно открыть эту же таблицу, встать на эту же запись и изменить поле Decimal1. Перейти на другую запись для ее сохранения и вернуться в первого клиента. В нем попробовать выйти из поля Code1. При этом появится сообщение об ошибке - другой пользователь изменил запись. А теперь самое интересное. Если открыть таблицу Test Commit, то в ней появилась запись, которая формируется на триггере OnValidate поля Code1 !!!! То есть оптимистическая конкуренция откатила транзакцию не польностью !!!!
Кто-нибудь встречался с этим ранее???

P.S. Ошибка появилась изначально на реальном проекте. Возникает на клиентах 3.70B и 4.0 SP1. БД - SQL.
Вложения
Тип файла: fob Test.fob (4.2 Кб, 524 просмотров)
Старый 03.05.2006, 17:48   #2  
NeNavision_imported is offline
NeNavision_imported
Участник
Аватар для NeNavision_imported
 
241 / 10 (1) +
Регистрация: 12.08.2005
По моему, данный результат никак не связан с оптимистической конкуренцией и транзакциями. Validate вызывается при необходимости проверки введенного значения, (грубо говоря с этого места в данном случае начинается транзакция). И благополучно завершается. Просто нужно учесть такую “особенность”. Хотя согласен, может являться очень большим источником проблем. Есть еще особенность, что Validate таблицы вызывается раньше validate формы (поля). Вообщем, есть чем заняться
__________________
Должен остаться только один.
Старый 03.05.2006, 18:42   #3  
Seer_imported is offline
Seer_imported
Участник
 
75 / 10 (1) +
Регистрация: 08.12.2005
Цитата:
Сообщение от NeNavision Посмотреть сообщение
По моему, данный результат никак не связан с оптимистической конкуренцией и транзакциями. Validate вызывается при необходимости проверки введенного значения, (грубо говоря с этого места в данном случае начинается транзакция). И благополучно завершается. Просто нужно учесть такую “особенность”. Хотя согласен, может являться очень большим источником проблем. Есть еще особенность, что Validate таблицы вызывается раньше validate формы (поля). Вообщем, есть чем заняться
То есть Вы хотите сказать, что изменения, которые являются следствием изменения данного поля (Code1) не откатываются, так как их начало и конец - есть начало и конец транзакции, а изменения, которые были ДО НИХ - откатываются???? Получается, что есть некоторая вложенная транзакция, которая не откатывается, в то время как основная - откатывается? По-моему, это в чистом виде глюк ядра.
Старый 04.05.2006, 09:44   #4  
NeNavision_imported is offline
NeNavision_imported
Участник
Аватар для NeNavision_imported
 
241 / 10 (1) +
Регистрация: 12.08.2005
Я думаю это принципиально разные транзакции. Чуть-чуть модифицируем ваш эксперимент. Сделаем так. В первом клиенте изменим поле code1 и не выходим их этого поля. Во втором клиенте изменяем поле Decimal1, переходим на другую запись тем самым, сохраняя изменения. Переключаемся на первого клиента и переходим из поля code1 только не на другую запись, а в другое поле данной записи например в тоже decimal1. Что получилось: изменения сделаны – сделаны. Программа запускает Validate поля code1, начинается транзакция, что-то она делает и благополучно заканчивается, внося изменения в другую табличку (Test Commit). О том, что данная запись была изменена в другом клиенте пока ничего не известно. Теперь из поля decimal1 переходим на другую запись и система ругается, что данная запись была изменена другим пользователем. Затем она изменяют эту запись на основе новых данных (полученных/измененных во втором клиенте). Таким образом создается впечатление, что произошел откат транзакции (поле code1 примет старое значение).
Вообщем, думаю - это такие тонкости, которые желательно знать.
__________________
Должен остаться только один.
Старый 04.05.2006, 10:34   #5  
Seer_imported is offline
Seer_imported
Участник
 
75 / 10 (1) +
Регистрация: 08.12.2005
Цитата:
Сообщение от NeNavision Посмотреть сообщение
Я думаю это принципиально разные транзакции. Чуть-чуть модифицируем ваш эксперимент. Сделаем так. В первом клиенте изменим поле code1 и не выходим их этого поля. Во втором клиенте изменяем поле Decimal1, переходим на другую запись тем самым, сохраняя изменения. Переключаемся на первого клиента и переходим из поля code1 только не на другую запись, а в другое поле данной записи например в тоже decimal1. Что получилось: изменения сделаны – сделаны. Программа запускает Validate поля code1, начинается транзакция, что-то она делает и благополучно заканчивается, внося изменения в другую табличку (Test Commit). О том, что данная запись была изменена в другом клиенте пока ничего не известно. Теперь из поля decimal1 переходим на другую запись и система ругается, что данная запись была изменена другим пользователем. Затем она изменяют эту запись на основе новых данных (полученных/измененных во втором клиенте). Таким образом создается впечатление, что произошел откат транзакции (поле code1 примет старое значение).
Вообщем, думаю - это такие тонкости, которые желательно знать.
Так вот и получается, что такая "тонкость" приводит к нарушению целостности данных - а это уже больше похоже на недоработку MBS. Гораздо логичнее было бы перед отработкой Validate проверять, во-первых, на основе последней ли версии записи осуществляется выполнение кода в Validate, а во-вторых, перед отработкой Validate лочить эту запись.
Старый 04.05.2006, 10:44   #6  
NeNavision_imported is offline
NeNavision_imported
Участник
Аватар для NeNavision_imported
 
241 / 10 (1) +
Регистрация: 12.08.2005
Согласен. Это плохо. Источник больших проблем.
Просто пытался объяснить, почему получается такой результат. Думаю, все-таки, это не ошибка целостности транзакций, но недоработка точно.
__________________
Должен остаться только один.
 


Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 07:11.