Как избавиться от расширенных свойств таблицы в SQL Server 2000?

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

Что у меня есть: Таблицы в БД на SQL Server 2000. Я просматриваю/редактирую таблицы с Access 2007, с SQL Server Management Studio 2005 и иногда с SQL 2000 Enterprise Manager.

Что я сделал: я попытался скопировать БД с SQL Server 2000 на свой локальный экземпляр SQL Server 2005. Копирование прошло без ошибок. Когда я попытался просмотреть таблицы в скопированной БД в Access 2007, у меня возникли исключения.

Что я обнаружил: таблицы, которые выдавали исключения, имели привязанные к ним расширенные свойства. Это я проследил до того, как сказал «да» для сохранения изменений в макете таблицы в Access.

Что я пытался сделать, чтобы исправить это: я попытался удалить расширенные свойства через SQL Server 2005 Management Studio и повторно скопировать БД, но это не решило проблему. При написании сценариев для таблиц я увидел, что расширенные свойства действительно не исчезли в таблицах.

Теперь мой вопрос:

С помощью Enterprise Manager я нашел таблицу sysproperties, которая находится в моей базе данных. Это может быть недокументированной таблицей (вздох), но похоже, что она имеет расширенную информацию о свойствах, которая вызывает у меня все головные боли. Я попытался изменить макет другой таблицы, чтобы узнать, были ли добавлены какие-либо записи в таблицу sysproperties, но, похоже, ответ был отрицательным.

У кого-нибудь есть опыт решения этой проблемы? Безопасно ли просто удалять записи в этой таблице? Я думаю, что большинство «изменений макета», которые я сделал, регулировали размер столбцов в Access, поэтому, если это все, что там хранится, я могу с этим смириться.

Более того, я искал расширенные свойства таблицы в Enterprise Manager, и они не были легко доступны, как в SSMS 2005.

Заранее спасибо!


person John    schedule 01.09.2009    source источник


Ответы (1)


Вы не говорите, является ли ваш фронт доступа MDB или ACCDB, но если это первый, почему бы не установить разрешения для TableDef, которые запрещают пользователям сохранять изменения дизайна? Вам нужно будет проверить это, но я думаю, что это свойства MODIFY DESIGN и ADMINISTER, которые вы хотели бы удалить из ссылок на таблицы в своем внешнем интерфейсе.

Если это ACCDB, возможно, единственный способ исправить это — воссоздать связанные таблицы.

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

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

Тем не менее, вы создаете собственную проблему, предоставляя пользователям прямой доступ к связанным таблицам. Исправьте это, и ваша проблема исчезнет, ​​не беспокоясь о разрешениях пользователей на таблицы в Access или SQL Server.

person David-W-Fenton    schedule 02.09.2009
comment
Спасибо Дэвид за ваш ответ. Я не указал это в вопросе, но мои пользователи получают доступ к таблицам через приложение, которое я пишу, а не через Access. Сохранение изменений макета было тем, что я сделал (не зная об этих запутанных последствиях) как разработчик приложения. - person John; 02.09.2009
comment
Таким образом, если вы не внесете эти изменения снова, проблема не повторится. Вы можете защитить себя от самих себя, если примените безопасность Jet ULS к связанным таблицам. Другим вариантом может быть удаление связанных таблиц и использование запросов со строкой подключения ODBC вместо связанных таблиц — в этом случае Access, скорее всего, не сохранит расширенные свойства. - person David-W-Fenton; 03.09.2009