Ошибка обновления строк в трехзвенке

[kgksoft]

Проблема следующая. Глюк воспроизводится в Axapta 3.0 только в трехзвенке и только с базой MS SQK2K5.

Axapta 3.0 SP4 KR3
MSSQL2K5 (Microsoft SQL Server Enterprise Edition 9.0.3228)
AOS - Windows 2000 Advanced Server SP4 (MDAC 2.8 SP1)

Периодически в разных местах возникает стандартное сообщение о том, что запись была обновлена на другом комьютере, нажмите Восстановить и т.д. и т.п.

Чаще всего эта проблема наблюдается при редактировании таблиц на DataSource'ах которых перекрыт метод active и в нем выполняются тяжеловесные операции.

Был проведен эксперимент. Создал новую таблицу с несколькими полями.Никаких свойств больше не менял. Создал новую форму и положил на нее грид для редактирования этой таблицы. Далее перехватил на DataSource метод active и добавил некий "тормоз":

public int active()
{
    int ret;
    int a = timenow();

    ret = super();
    while (timenow()<=a){}

    return ret;
}

после этого запустил форму. добавил несколько строк и после непродолжительных (до 100 изменений ) манипуляций и изменений полей всплывает вышеописанный глюк. Естественно, в масштабах предприятия глюк возникает намного!!! чаще. Помогите

P.S.
Включать в базе режим совместимости с SQL2000 еще не пробовал, но не хотелось бы делать downgrade.

[mazzy]

Цитата:

Сообщение от kgksoft

Чаще всего эта проблема наблюдается при редактировании таблиц на DataSource'ах которых перекрыт метод active и в нем выполняются тяжеловесные операции.

Ну, дык не делайте ваших "тяжеловесных операций".
Вынесите их на отдельную кнопку.

Про "глюк" - ищите в ваших "тяжеловесных операциях" метод update.
Ваша ошибка в том, что в момент ПРОСМОТРА вы делаете ОБНОВЛЕНИЕ. Перенесите обновление записи в метод write и "глюк" волшебным образом исчезнет.

[kgksoft]

Цитата:

Сообщение от mazzy

Ну, дык не делайте ваших "тяжеловесных операций".
Вынесите их на отдельную кнопку.

Все бы хорошо, но иногда глючит и стандарные операции. Например редактирование номенклатурного справочника. Кроме того, это не решение проблемы. В вышеприведенном примере я не делал ничего запрещенного, а глюк вылез.

[glibs]

Цитата:

Сообщение от kgksoft

...
в масштабах предприятия глюк возникает намного!!! чаще
...

В масштабах предприятия вы от него и не избавитесь. Что у вас за справочник, что вы его постоянно обновляете? Да еще и так интенсивно. Он обновляется только из интерфейса, или из кода тоже?

Этот глюк постоянно вылазит, если на таблице включен Entire table cache. Я иногда на время интенсивной настройки системы снимаю кэширование со справочников даже. Он у меня воспроизводился на всех версиях 3.0 на MS SQL 2000.

[kgksoft]

Цитата:

Сообщение от glibs

В масштабах предприятия вы от него и не избавитесь. Что у вас за справочник, что вы его постоянно обновляете? Да еще и так интенсивно. Он обновляется только из интерфейса, или из кода тоже?

Чаще всего ошибка возникает при редактировании строк журнала собственной разработки. На методе WRITE сидит довольно тяжелые операции вызова T-SQL, но я убирал абсолютно весь кустарный обновляющий код и глюк вылезал все равно, но намного реже. Т.е. обычное!!! редактирование строк в таблице с большим числом записей !!! (Глюк ядра ?)

Цитата:

Сообщение от glibs

Этот глюк постоянно вылазит, если на таблице включен Entire table cache.

Кэш для этих таблиц выключен.

Более того, возвращаясь к моему тестовому примеру:
1. Там кэша нет.
2. С таблицей работаю только я и в одном окне
при этом ошибка возникает.

[kgksoft]

Только пофиксил баг. Ох и крови он попил. А проблема была в том, что при активном использовании прямых SQL-запросов в них для работоспособности нужно указывать директиву "set nocount on". Вот мы и указывали, а выключать "set nocount off" забывали (не знали).
Дальше лучше. Такие сессии SQL-сервера случайным образом выделяль AOS-ом ни в чем не повинным пользователям (АОС SQL-сессии не закрывает, а выдает при надобности) и выдавали сообщение о невозможности сохранить запись (оновлена другим пользователем) в самых безобидных случаях. На произвольных таблицах и формах.
Более того, проблемы возникали и в толстом клиенте, но намного реже. Реже использовался функционал "set nocount on".

[Logger]

Цитата:

Сообщение от kgksoft

...Ох и крови он попил. А проблема была в том, что при активном использовании прямых SQL-запросов в них для работоспособности нужно указывать директиву "set nocount on". Вот мы и указывали, а выключать "set nocount off" забывали (не знали).

А как вы диагностировали проблему ? Это же найти надо было...
Просто догадались ?

[kgksoft]

Это давно было в Ax 3.0. Пользователи жаловались на странные сообщения про невозможность обновить строку, которую только этот пользователь и правил.

Диагностировал на системе без пользователей на форме на которой из необычного было только вызов хранимки MSSQL для заполнения вспомогательных строк в строках кастомного журнала.