Доступность собственных таблиц после импорта проекта

[Narayana]

5.0.1500.6491

После импорта собственного проекта в заново установленную Аксапту при попытке открыть для просмотра одну из импортированных с проектом таблиц, система выдает сообщение "Недостаточно прав для использования таблицы".

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

Ситуация настолько дурацкая, что никаких мыслей не приходит.
Если кто-нибудь сталкивался с таким явлением, прошу откликнуться.

[Удвой Покуров]

На какой слой импортируете? Из под какой учетки? Попробуйте "установить права" администратора - должо помочь. Но симптомы странные, "то есть, то нет"

[Narayana]

Цитата:

Сообщение от Удвой Покуров

На какой слой импортируете? Из под какой учетки? Попробуйте "установить права" администратора - должо помочь. Но симптомы странные, "то есть, то нет"

Импортирую на слой "USR" из под учетной записи администратора домена, под которой и устанавливалась Аксапта и все остальное, включая SQL Server.
Права администратора, вроде бы установлены уже, потому как на момент импорта никаких других пользователей в Аксапте создано еще не было.

Попробовал создать еще одного пользователя с админскими правами и дать ему все разрешения через разрешения для групп пользователей, - то же самое.

Делаю дубликат таблицы, - он тоже не открывается для просмотра. Пытаюсь изменить имя дубликата, выдает ошибку "Неправильное значение свойства" и не дает переименовать.
Симптомы, да, странные.
Но, все именно так.
Одни из импортированных таблиц открываются для просмотра данных, а другие нет.
Хотя, те и другие доступны для изменения конструкции таблиц в АОТе.

[S.Kuskov]

Проект импортировался с сохранением id?
Свойство SecurityKey на таблицах заполненное или пустое?

[Narayana]

Цитата:

Сообщение от S.Kuskov

Проект импортировался с сохранением id?
Свойство SecurityKey на таблицах заполненное или пустое?

Проект импортировался без сохранения id.
SecurityKey = Employee_RU.
Если это свойство и свойство конфигурационного ключа очистить, таблица становится доступной.
При этом все другие родные таблицы имеющие такое же свойство SecurityKey также не открываются для просмотра.

Это нормально?

[Ivanhoe]

Цитата:

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

При этом все другие родные таблицы имеющие такое же свойство SecurityKey также не открываются для просмотра.

Т.е. все стандартные таблицы с таким ключом не доступны? У вас, возможно, выключен конфигурационный ключ "Подотчетные лица"?

[Narayana]

Цитата:

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

Т.е. все стандартные таблицы с таким ключом не доступны? У вас, возможно, выключен конфигурационный ключ "Подотчетные лица"?

В свойствах конфигурационного ключа Employee_RU поле LicenseCode пусто, а в поле ParentKey стоит CRSEMultiple. У ключа CRSEMultiple другой родитель и т.д., что в конечном счете ведет к лицензионному коду SysUser.
Вроде бы, это должно говорить о том, что конфигурационный ключ Employee_Ru включен...
Или я что-то не так понимаю?
Правда, в информации о лицензии у меня есть только строка Users, но строки SysUsers нет.
Может быть в этом причина?

[S.Kuskov]

Лиценционные ключи регулируют возможность включения конфигурационных ключей. Конфигурационные ключи могут быть выключены в Администрирование\Настройка\Система\Конфигурация.

[Narayana]

Цитата:

Сообщение от S.Kuskov

Лиценционные ключи регулируют возможность включения конфигурационных ключей. Конфигурационные ключи могут быть выключены в Администрирование\Настройка\Система\Конфигурация.

В этой форме, вроде бы, все включено...

[Narayana]

Цитата:

Сообщение от S.Kuskov

Лиценционные ключи регулируют возможность включения конфигурационных ключей. Конфигурационные ключи могут быть выключены в Администрирование\Настройка\Система\Конфигурация.

м-м-м... а установка GLSEE требует дополнительных лицезионных ключей, следствиеем чего в информации о лицензиях в партнерских модулях должна появиться строка типа строки управления Основными средствами, или GLSEE накатывается так же, как и SP1, без требования дополнительных лицензий?

И, кстати, не знаете, что за запись "Невозможно отредактировать запись в Данные пользователя (SysUserInfo).
Запись не выбрана" появляется всякий раз, когда вы первый раз запускаете клиента перед выполнением контрольного списка на чистой установке?

[S.Kuskov]

Цитата:

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

м-м-м... а установка GLSEE требует дополнительных лицезионных ключей, следствиеем чего в информации о лицензиях в партнерских модулях должна появиться строка типа строки управления Основными средствами, или GLSEE накатывается так же, как и SP1, без требования дополнительных лицензий?

Всё зависит от того связаны ли соответствующие конфигурационные ключи с лицензионными кодами или нет. Это можно увидеть в свойствах ConfigurationKey.
Установка Ax2009.Контрольный список.Ошибка.

Цитата:

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

И, кстати, не знаете, что за запись "Невозможно отредактировать запись в Данные пользователя (SysUserInfo).
Запись не выбрана" появляется всякий раз, когда вы первый раз запускаете клиента перед выполнением контрольного списка на чистой установке?

Метод find на таблице SysUserInfo имеет не совсем тривиальную реализацию. Вот видимо там где-то что-то и не сростается
Вот ещё ветка об этой ошибке Установка Ax2009.Контрольный список.Ошибка.

[Narayana]

Цитата:

Сообщение от S.Kuskov

Всё зависит от того связаны ли соответствующие конфигурационные ключи с лицензионными кодами или нет. Это можно увидеть в свойствах ConfigurationKey.
Установка Ax2009.Контрольный список.Ошибка.

Немного поупражнялся с формой лицензионных ключей, оказывается, по каждому codeline можно вывести список таблиц, которые от него зависят. Те, которые у меня не открываются, зависят от codeline "Users", но лицензия на него, естественно, есть.
То есть, таблицы не открываются не по причине лицензий и конфигурационныз ключей.
А у вас таблицы EmplTrans_RU или EmplParameters_RU открываются для просмотра данных?

Цитата:

Сообщение от S.Kuskov

Метод find на таблице SysUserInfo имеет не совсем тривиальную реализацию. Вот видимо там где-то что-то и не сростается
Вот ещё ветка об этой ошибке Установка Ax2009.Контрольный список.Ошибка.

Почитал...
К сожалению, ветка ни о чем.
Ну, если, конечно, дело, действительно, ни в том, чтобы перезапустить AOS перед первым запуском клиента после накатывания GLSEE.
А какую там запись в данных пользователя Аксапта не может отредактировать, - это, вообще, что-то эзотерическое. Иех... сколько человеко-лет уходит только потому, что кому-то лень было написать лишних два слова... ((

Но, тем не менее, ассоциация близкая, - таблицы не открываются, ссылаясь на недостаток прав юзера, ошибка при инициализации системы тоже на юзера грешит.
Попробовать что ли заново установить систему и подчеркнуто перезапустить AOS? Только сдается мне, что я его и так перезапускал, а эта ошибка выскакивает при любой инициализации, независимо от обновления или базовой установки....

[Владимир Максимов]

Не уверен, что дело именно в этом, однако в ранних версиях Axapta наблюдался следующий глюк.

Если в системной таблице \System Documentation\Tables\AccessRightsList нет ни одной записи соответствующего домена, то с правами доступа вообще ничего невозможно сделать. Ни назначить, ни удалить. Ну, и, естесственно, нет доступа к таблице. В качестве "лечения" приходилось вручную создавать в этой таблице запись с правами админстратора в соответствующем домене. После чего уже назначать права доступа как обычно.

Посмотрите, есть ли вообще в этой таблице записи для нужного домена.

[Ivanhoe]

Таблицы EmplTrans_RU и т.п. открываются, если включен конфиг. ключ Функции для страны /региона - Несколько стран / регионов - Подотчетные лица. Особых лицензий для этого не нужно, если в AOT таблица есть, значит и слой локализации установлен.

По поводу ошибки с пользователем - у вас в итоге не получается зайти в систему? Или просто ругается, но аксапта работает? Первый случай похож на ситуацию, когда сначала ставится Акс с последними Roll-up и только потом запускается первый раз - из-за мексиканской локализации какие-то поля отсутствуют в таблице и система не стартует - поищите, обсуждалось на форуме.

[Narayana]

Цитата:

Сообщение от Владимир Максимов

Не уверен, что дело именно в этом, однако в ранних версиях Axapta наблюдался следующий глюк.

Если в системной таблице \System Documentation\Tables\AccessRightsList нет ни одной записи соответствующего домена, то с правами доступа вообще ничего невозможно сделать. Ни назначить, ни удалить. Ну, и, естесственно, нет доступа к таблице. В качестве "лечения" приходилось вручную создавать в этой таблице запись с правами админстратора в соответствующем домене. После чего уже назначать права доступа как обычно.

Посмотрите, есть ли вообще в этой таблице записи для нужного домена.

Нашел указанную вами таблицу на SQL сервере.
Записей там 57. Насколько я понял, все они соответствуют codeline лицензии.
И у всех поле домена заполнено Admin.

Больше интересно другое.
Те таблицы, которые у меня не открываются для просмотра (EmplTrans_RU, EmplLeger_RU и т.д.)... то есть, таблицы, которые, вроде бы, должны были добавиться в систему после накатывания GLSEE, в базе данных на SQL сервере ...просто отсутствуют.
Вообще, ничего не понимаю...

[Narayana]

Цитата:

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

Таблицы EmplTrans_RU и т.п. открываются, если включен конфиг. ключ Функции для страны /региона - Несколько стран / регионов - Подотчетные лица. Особых лицензий для этого не нужно, если в AOT таблица есть, значит и слой локализации установлен.

По поводу ошибки с пользователем - у вас в итоге не получается зайти в систему? Или просто ругается, но аксапта работает? Первый случай похож на ситуацию, когда сначала ставится Акс с последними Roll-up и только потом запускается первый раз - из-за мексиканской локализации какие-то поля отсутствуют в таблице и система не стартует - поищите, обсуждалось на форуме.

В том-то и дело, что в АОТе таблицы есть, но не открываются для просмотра с сообщением, что недостаточно прав. А вот в базе данных этих таблиц просто нет.

По поводу ошибки с пользователем, - система при первом запуске просто ругается, но в систему пускает. Причем, независимо от того, первый ли это запуск без обновлений или после обновлений.
Сначала я думал, что это просто глюк, а вот сейчас засомневался...
И главное, непонятно, про какую запись она вещает, которую невозможно отредактировать...?

[Ivanhoe]

Синхронизация таблиц выполнялась? Если не помогает, попробуйте все-таки лицензии перезалить.

[S.Kuskov]

Цитата:

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

В том-то и дело, что в АОТе таблицы есть, но не открываются для просмотра с сообщением, что недостаточно прав. А вот в базе данных этих таблиц просто нет.

Так происходит если соответствующие конфигурационные ключи выключенны.

Цитата:

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

В этой форме, вроде бы, все включено...

Проверьте ещё раз в этой форме по указанному Ivanhoe пути:

Цитата:

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

Таблицы EmplTrans_RU и т.п. открываются, если включен конфиг. ключ Функции для страны /региона - Несколько стран / регионов - Подотчетные лица.

[Narayana]

Цитата:

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

Синхронизация таблиц выполнялась? Если не помогает, попробуйте все-таки лицензии перезалить.

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

[Narayana]

Цитата:

Сообщение от S.Kuskov

Так происходит если соответствующие конфигурационные ключи выключенны.



Проверьте ещё раз в этой форме по указанному Ivanhoe пути:

...уй, ё-ё-ё...!!!
...какой же я дурной, однако...!
Ну, конечно, "несколько стран/регионов" галочка выключена...!
Я как-то на автомате смотрел всегда только на то, что включена "Россия", а что для работы с несколькими странами нужно включить отдельную галочку, даже и забыл. А ведь когда-то помнил... ))

Бяда с большими системами. Через пару месяцев, вообще, забываешь где был и что делал.

Всем спасибо за участие, узнал кое-что новое! )