Синхронизация и SQL

[Swetik]

При синхронизации в Аксапте на SQL Servere 2000 в двух-уровневой конфигурации
владелец-создатель таблиц (Owner)- DBO, при синхронизации в 3-х звенке на том же сервере - Владельцем таблиц как-то выборочно становится - Owner - Bmssa . В итоге в Аксапте вылезают ошибки (ошибка MS Sql). Где может быть тут зарыта ошибка ?

[Maxim Gorbunov]

А в файлах конфигурации Axapta какие пользователи SQL стоят (закладка SQL Server в 3.0 или ODBC в 2.5)?

[Swetik]

user Id - bmssa

[Maxim Gorbunov]

В обоих? И в двухуровневой конфигурации тоже?

Кстати, версия Аксапты какая?

[Swetik]

Axapta 3.0 - и в конфигурации на AOS, и конфигурации на клиенте - bmssa

[Михаил Андреев]

А зачем bmssa лишние права?
Нужно отобрать все серверные права типа DBO и т.п.

Хотя такую кривость я даже и не видел, но, думаю, дело именно в ней: при синхронизации часть таблиц создается заново, в двухуровневой от DBO (ибо право такое есть), а в трехуровневой - непонятно как, я экспериментировал без лишних прав, тогда получалось нормально. Кстати, у вас, похоже, еще и клиент может быть виноват (если толстый).

[Maxim Gorbunov]

Проверьте права bmssa в используемой БД (должны быть все, кроме db_deny*). Если все нормально, возможно таблицы в двухуровневой конфигурации были созданы при настройках, отличных от настоящих (скорее login bmssa был ассоциирован с пользователем dbo).

Чтобы избавиться от ошибок, поменяйте владельца всех User-таблиц на bmssa. Можно воспользоваться скриптом вот отсюда: http://www.axforum.info/forums/showt...s=&threadid=41 (не забудьте поменять имена пользователей axwork на dbo, а axtest на bmssa).

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Михаил Андреев
А зачем bmssa лишние права?
....
я экспериментировал без лишних прав, тогда получалось нормально.

А вот отсюда поподробнее, пожалуйста. Какие права нужно дать bmssa, а без каких он может обойтись? Я по старинке выставляю все, кроме deny, но, видимо, я не прав.

2Swetik
Кстати, на всякий случай напомню, что в конфигурации для 3.0 лучше не указывать Data Source.

[Swetik]

Спасибо - получилось.

[Михаил Андреев]

Максим!

[FIG1]

Я имел в виду, что не нужно давать bmssa какие-либо серверные права (роли), как на рисунке, а права в конкретной базе описаны подробно в мануале - все, кроме "*deny*".

Просто при наличии серверной роли у bmssa при синхронизации вместо bmssa владельцем таблиц будет dbo.

В мануале, кстати, (я помню в 2.5 еще), описано, чтобы лишних ролей bmssa не давали на рабочей базе, а для разработки типа можно

[Swetik]

Но я проставила не права - а ServerRole -Все. А права оставила public и db_owner

[Михаил Андреев]

Рисунок не прошел
Объясню словами:
Для пользователя bmssa на закладке Server Poles убираем все флажки, а на закладке Database Access для конкретной базы устанавливаем все флажки, кроме последних двух, начинающихся с db_deny*.

[Maxim Gorbunov]

Миша, Server Roles назначаются не пользователям, а логинам (так как это роли для сервера, а не для одной БД), хотя в принципе все равно понятно, что ты имел ввиду:

1. Логин bmssa не должен быть членом какой-нибудь серверной роли.
2. Пользователь БД bmssa, ассоциированный с логином bmssa, должен иметь в БД все права, кроме db_deny*

Цитата:

Изначально опубликовано Михаил Андреев
Просто при наличии серверной роли у bmssa при синхронизации вместо bmssa владельцем таблиц будет dbo

Какой именно роли. У меня обычно, конечно, bmssa не имеет никаких ролей, но тем не менее, все равно интересно, принадлежность какой роли обеспечивает описанный эффект?

[Maxim Gorbunov]

Кстати, для интересующихся. В Navision Axapta Configuration Utility вы указываете логин на сервер, а не пользователя БД.

[Vadik]

Цитата:

У меня обычно, конечно, bmssa не имеет никаких ролей, но тем не менее, все равно интересно, принадлежность какой роли обеспечивает описанный эффект?

дык, sysadmin

[Maxim Gorbunov]

Да простят меня ненавистники MS за то, что я ищу логику в их программах! В общем, нелогично это как-то. Залогинены мы в сервер, как bmssa. Пусть у него даже роль sysadmin есть. Логин связан с юзером БД bmssa. С какого перепою создающиеся таблицы преписываются dbo??? Хоть убейте, не пойму.

А результат, описанный в самом первом постинге, у меня прекрасно получался, когда логин bmssa был сначала связан с dbo, а потом его все-таки решили перепривязать.

[Vadik]

Цитата:

С какого перепою создающиеся таблицы преписываются dbo??? Хоть убейте, не пойму

The dbo is a user that has implied permissions to perform all activities in the database. Any member of the sysadmin fixed server role who uses a database is mapped to the special user inside each database called dbo.

[Maxim Gorbunov]

А если логин уже примаплен к bmssa? Ведь нельзя мапить один логин двум пользователям БД.

[Vadik]

Цитата:

А если логин уже примаплен к bmssa?

Это как?

[Maxim Gorbunov]

Так, секундочку. Разбираемся в терминологии.

1. Есть логины на сервер. В EM они указываются в ветке Security - Logins. Логин имеет пароль и, возможно, несколько серверных ролей.
2. Есть серверные роли (Server Roles). Они перечислены в EM в ветке Security - Server Roles. Серверные роли предопределены и не изменяются.
3. Есть пользователи БД (Database Users). В EM они перечислены в ветке Databases - <Имя БД> - Users. Пользователи являются сущностью, принадлежащей БД (отражено в их размещение в дереве). У них имеется набор прав на БД, которой они принадлежат. Они ассоциированы (mapped на русский не знаю как по-другому перевести) с логинами.

Когда пользователь (человек) входит на сервер, он указывает логин и его пароль. При этом, если он работает с какой-либо БД, действия рассматриваются, как выполненные пользователем, который в этой БД ассоциирован с данным логином.

Так вот, один логин, на сколько я знаю (я не MCDBA, к сожалению ), не может быть ассоциирован более, чем с одним пользователем в каждой БД. Если bmssa уже ассоциирован с юзером bmssa, почему его действия рассматриваются, как действия dbo? Это и был вопрос.