Need help ошибка Неправильный тип индекса массива.

[Evgeniy2020]

Ошибка времени выполнения. : Неправильный тип индекса массива.

При попытке изменить данные на форме закупок (практически любое поле в таблице Закупки)
в системном методе \Classes\FormDataSource\validateWrite вылетает ошибка
ошибка только у одного пользователя и только на рабочем приложении.
на тестовом приложении и базе данных все в порядке у того же пользователя, ошибка не возникает. У пользователя админские права,
но и под адм правами ошибка вылетает. у других пользователей такой проблемы нет.

(C) \Classes\FormDataSource\validateWrite
(C) \Forms\PurchTable\Data Sources\PurchTable\Methods\validateWrite - line 31

---------------------------
Microsoft Business Solutions-Axapta Debugger
---------------------------
Ошибка времени выполнения. : Неправильный тип индекса массива.

Трассировка стека:
(C) \Classes\FormDataSource\validateWrite
(C) \Forms\PurchTable\Data Sources\PurchTable\Methods\validateWrite - line 31
---------------------------
ОК
---------------------------


аксапта ax 3.0 ee sp5 fp2
база ms sql 2005 sp2


Может есть у кого то догадки как это побороить или в чем причина?
спасибо заранее

[egorych]

1. Удалить файл юзверьского кэша - в 90 % помогает
2. Очистить настройки формы
3. Компильнуть форму

[konfet]

У меня была такая же ошибка, у конкретного пользователя, на конкретной таблице. Появлялась также после корректной отработки validatewrite() на таблице. Сбросы кэшей, компиляции-синхронизации и тп не помогли.
Собака оказалась зарыта в правах. У пользователя было 200+ назначенных ему групп, в некоторых из которых права были настроены криво.

[Romb]

Добрый день. Только что возникла такая проблема, исследование показало следующее.

Такая проблема бывает из-за того что в настройке безопасности на уровне записей для какой-либо таблицы сохранен запрос по другой таблице. Т.е. при срабатывании механизма прав на уровне записей одной таблицы, ядро пытается применить сохраненные в таблице SysRecordLevelSecurity критерии (упакованный query) по полям другой таблицы. Что, как кажется, сносит системе крышу, но, в общем, обрабатывается корректно с точки зрения системы

Т.е. зависимость от настройки прав тут выступает в части настройки доступа на уровне записей для групп пользователей.
Само же некорректное сохранение запроса по одной таблице для другой таблицы не знаю точно как происходит, но замечал, что это иногда случается. Тут причины могут быть очень разные.

В общем решение - проверить/пересоздать настройки безопасности на уровне записей по проблемной таблице для группы, в которой происходит инцидент.