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

[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 для заполнения вспомогательных строк в строках кастомного журнала.