Владельцы таблиц в БД аксапты

[AxaptaUser]

В последнне время пришлось столкнутся с проблемой (до этого проблем не возникало) восстановления БД с одного сервера на другой (сиквел). Аксапта (v.3.0 sp 3) на восстановленной БД не видела 100 своих таблиц, после долгих мучении прогона скрипта вроде всё нормализовалось. Но меня заинтересовали следующие вопросы:
- Кто должен быть владельцем таблиц БД?
- Владелец должен быть один для всех таблиц?
Сейчас ситуация в моей рабочей базе следующая:
- владелец БД - пользователь домена;
- bmssa - user в сиквеле и БД;
- владелец части таблиц - bmssa, другой части таблиц - dbo;
- bmssa и владелец БД не входят в группу system administrators.

Есть сомнения, что такая ситуация не совсем правильная. так ли это? И как могло произойти так, что у таблиц разные владельцы.

Спасибо.

[Sada]

Помоему должны быть все dbo.Давно с этим ен стталкивался - могу наврать. А работает то щас чёнить или нет?

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

Цитата:

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

Помоему должны быть все dbo.Давно с этим ен стталкивался - могу наврать. А работает то щас чёнить или нет?

Не обязательно dbo для версии 3.0. Но то, что у всех таблиц должен быть один владелец, это точно. А вот как такого добились, не знаю.

[glibs]

Цитата:

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

...
И как могло произойти так, что у таблиц разные владельцы.
...

Скорее всего, у вас двухзвенка или толстый клиент, и часть пользователей подключается к БД как sa, а часть как bmssa. И по очереди запускают синхронизацию таблиц. Я где-то видел уже такую базу. Там БД была создана под sa, а потом кто-то программировал под bmssa, и часть таблиц перекочевала под bmssa.

Ситуация с двумя владельцами dbo и bmssa рабочая, насколько я знаю.

[veps]

вы можете поменять владельца таблиц в SQL
http://axapta.mazzy.ru/lib/2db_owner/

у нас возникала подобная ситуация при синхронизации таблиц в двухзвенке, админ так настроил кластер и sql ( безопасность )

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

Цитата:

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

Скорее всего, у вас двухзвенка или толстый клиент, и часть пользователей подключается к БД как sa, а часть как bmssa. И по очереди запускают синхронизацию таблиц. Я где-то видел уже такую базу. Там БД была создана под sa, а потом кто-то программировал под bmssa, и часть таблиц перекочевала под bmssa.

Ситуация с двумя владельцами dbo и bmssa рабочая, насколько я знаю.

Не всегда. Если вдруг добавили прав bmssa, он легко станет dbo

[ntr]

Действительно синхронизация и разработка под AOS
http://support.microsoft.com/kb/275312 (SQL Server Procedure to Change Object Owner)

[AxaptaUser]

Спасибо всем.
База рабочая - то есть в ней работают и особых проблем не возникает (трехзвенка, тонкий клиент).
Прояснилась ситуация с тем, как образовались разные владельцы объектов.
При перенесении БД с одного сервера на другой был создан пользователь БД bmssa с правами db_owner, под которым и входила Аксапта в БД.
Соответственно при создании объектов или синхронизации, владельцем становился bmssa.
Поменять владельцев объектов удалось с помощью скрипта, изложенного на http://www.axforum.info/forums/showt...395#post114395 или http://www.axforum.info/forums/showt...invalid+object. После этого был удален из пользователей БД bmssa, а владельцем БД был назначен bmssa.

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

На будущее: в МС сделали хранимую процедуру sp__foreachtable, которая выполняет какие-то действия со всеми таблицами базы данных: http://www.databasejournal.com/img/N...ode.html#code1

[AxaptaUser]

Цитата:

Сообщение от Михаил Андреев

На будущее: в МС сделали хранимую процедуру sp__foreachtable, которая выполняет какие-то действия со всеми таблицами базы данных: http://www.databasejournal.com/img/N...ode.html#code1

Спасибо. Думаю пригодится.

[Raven Melancholic]

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

[KiselevSA]

Цитата:

Сообщение от Raven Melancholic

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

Например, отсюда http://www.sql.ru/forum/actualthread.aspx?tid=3484