Форум: "Базы";
Текущий архив: 2002.05.30;
Скачать: [xml.tar.bz2];
ВнизКак граммотно обеспечить доступ к сис.таблице? Найти похожие ветки
← →
MaXie (2002-05-06 11:39) [0]Вопрос претендует на оффтопик, но все же - может кто подскажет?
В системную таблицу tbTable1 (MS SQL Server 2000), через клиента (Delphi 5) необходимо добавить строку с данными. В явном виде доступа к tbTable1 нет (SELECT и INSERT явно не указаны!). Вставка строк осуществляется через представление VIEW1, доступ к которому на уровне SELECT и INSERT разрешен.
Если работу клиента организовать через tbTable1 (, к полям которой предварительно указать доступ SELECT и INSERT), все работает. Если доступ клиента к tbTable1 "завести" через представление VIEW1 (SELECT и INSERT указаны явно!), выдается окно об ошибке - "в таблице tbTable1 запрещено выполнение команды INSERT".
Как обойти эту проблему или в чем возникает ошибка уровня прав доступа?
P.S. В Access все работает, в Delphi та же схема внесения данных не проходит. :(
← →
Johnmen (2002-05-06 12:38) [1]1. Если правильно понял, то VIEW1 должен отвечать некоторым требованиям, чтобы быть редактируемым.
2. >>>в Delphi та же схема внесения данных не проходит
Delphi непричем, причем MSSQL...
← →
MaXie (2002-05-06 13:05) [2]Но каким образом в этом случае организовать доступ к системной таблице? Дать прямой доступ SELECT и INSERT?
To Johnmen:
>>Delphi непричем, причем MSSQL...
В одной из тем, здесь же, утверждалось, что Delphi работает с представлениями MS SQL точно так же, как и с таблицами! Но при работе с таблицами MS SQL подобной проблемы не возникает, так в ком возникает проблема - в MS SQL или все же в Delphi?
← →
Reindeer Moss Eater (2002-05-06 13:17) [3]Server Behavior
"Allow modifications to be made directly to system catalog"
или sp_configure "allow updates"
← →
mad0max (2002-05-06 13:26) [4]to MaXie
Хранимые процедуры я думаю тебя спасут
← →
MaXie (2002-05-06 13:26) [5]To Reindeer Moss Eater:
>>Server Behavior
>>"Allow modifications to be made directly to system catalog"
Можно чуть по-подробней?
← →
Johnmen (2002-05-06 13:27) [6]Delphi работает с наборами данных, и от того, как они получены и из чего, зависит функциональность этой самой работы.
← →
Reindeer Moss Eater (2002-05-06 14:18) [7]В свойствах MSSQL есть параметр который зовется как я уже сказал.
Именно он не разрешает INSERT и UPDATE для системных таблиц.
Изменить его можно через Enterprise Manager или через вызов sp_configure.
Delphi здесь действительно не при чем. Прямая модификация недоступна из любого инструмента если этот параметр снят.
← →
MaXie (2002-05-06 14:36) [8]Да, но речь идет не о системных таблицах на уровне MS SQL Server, а о системных таблицах на уровне пользовательской БД. В данном случае, это таблица к которой пользователь не имеет прямого доступа и в которой, кроме его данных (данных пользователя), хранится еще кое-какая системная информация, скрытая от пользователя БД! Доступ на просмотр и вставку строк к таким таблицам обычно организуют через представления.
Клиент написанный на Delphi вставку данных через представления в таблицы (, доступ к которым организован исключительно через представления), обеспечить не может! Существует ли в Delphi способ, при котором в таблицу, доступ к которой явно не указан, оказывается возможным вставить в нее данные?
← →
Reindeer Moss Eater (2002-05-06 14:43) [9]Нормально. В 11:39 речь шла о системных таблицах, сейчас выясняется, что это пользовательские данные.
Давай сюда скрипт твоего просмотра.
← →
Johnmen (2002-05-06 15:12) [10]>Существует ли в Delphi способ, при котором в таблицу, доступ к
>которой явно не указан, оказывается возможным вставить в нее
>данные?
Этот способ должен существовать не в Delphi !!!
А если точнее - то он существовать НЕ ДОЛЖЕН в соответствии с общей концепцией построения СУБД !!!
← →
MaXie (2002-05-06 15:45) [11]To Reindeer Moss Eater:
>>Давай сюда скрипт твоего просмотра.
Скрипт самого представления?
To Johnmen:
>>НЕ ДОЛЖЕН в соответствии с общей концепцией построения СУБД !!!
Упрощая до предела постановку задачи:
В таблице содержится информация, вносимая несколькими группами пользователей. Каждая группа может просматривать только те данные, которые были внесены ее пользователями (пользователями именно этой группы), и не может просматривать данные другой группы! Какой, в этом случае, необходимо избрать инструмент для ограничения доступа к информации, неотносящейся к данной группе? Команда SELECT для каждой из групп может быть применена только ко всей таблице, но ни как не к отдельным строкам или группам строк, т.е. любая из групп будет видеть абсолютно всю информацию, содержащуюся в таблице (информацию всех групп). Создавать отдельную таблицу для каждой группы - на лицо противоречие концепции построения СУБД (групп может быть несколько сотен, а то и тысяч)! Наиболее гибкий и доступный способ ограничения доступа - ПРЕДСТАВЛЕНИЯ.
Если это все является моим заблуждением, то убедительная просьба подсказать, как правильно построить БД применительно к описанному выше случаю?
P.S. Прошу прощения, если вопрос покажется "флеймовым".
← →
Reindeer Moss Eater (2002-05-06 15:48) [12]>MaXie ©
Его конечно же
← →
Johnmen (2002-05-06 16:04) [13]Что касается селектов, то в упомянутой тбл необходимо поле, однозначно идентифицирующее группу пользователей, а далее применяя view и ХП обеспечить разграничение доступа...
← →
MaXie (2002-05-06 16:38) [14]To Reindeer Moss Eater:
Жутко криво и упрощая до невозможности:
CREATE VIEW dbo.[Представление Заявка на списание]
AS
SELECT dbo.[Базовая таблица].Литера, dbo.[Базовая таблица].Списать, dbo.[Базовая таблица].Дата, dbo.[Базовая таблица].Получатель, dbo.[Базовая таблица].Отправитель, dbo.[Базовая таблица].НДС, dbo.[Базовая таблица].Назначение, dbo.[Базовая таблица].ИНН, dbo.[Базовая таблица].РС, dbo.[Базовая таблица].КС, dbo.[Базовая таблица].[Банк получателя], dbo.[Базовая таблица].место, dbo.[Базовая таблица].организация, dbo.[Базовая таблица].IdUSD, dbo.[Базовая таблица].БИК
FROM dbo.USD INNER JOIN
dbo.[Базовая таблица] ON dbo.USD.IdUSD = dbo.[Базовая таблица].IdUSD INNER JOIN dbo.Литера ON dbo.[Базовая таблица].Литера = dbo.Литера.Литера INNER JOIN dbo.НДС ON dbo.[Базовая таблица].НДС = dbo.НДС.НДС
WHERE (dbo.[Базовая таблица].Дата = 0)
To Johnmen:
>>а далее применяя view и ХП обеспечить разграничение доступа...
Поле однозначно идентифицирующее группу пользователей уже существует. Можно пояснить что такое view и ХП? И как с помощью их разграничить доступ?
Выходит что без представлений ни как не обойтись?
← →
Reindeer Moss Eater (2002-05-06 16:51) [15]Представление MSSQL на основе двух таблиц без агрегатов допускает обновление.
Три и более - врать не стану, но по-моему нет.
← →
Reindeer Moss Eater (2002-05-06 17:02) [16]Наврал. Количество таблиц не имеет значения.
А какой именно insert не проходит?
← →
MOA (2002-05-07 11:42) [17]Дело в том, что если не принимать спец. мер, клиент будет пытаться сделать UPDATE для базовой таблицы. Далее цитата из BOL:
CREATE VIEW [ < database_name > . ] [ < owner > . ] view_name [ ( column [ ,...n ] ) ]
[ WITH < view_attribute > [ ,...n ] ]
AS
select_statement
[ WITH CHECK OPTION ]
< view_attribute > ::=
{ ENCRYPTION | SCHEMABINDING | VIEW_METADATA }
VIEW_METADATA
Specifies that SQL Server will return to the DBLIB, ODBC, and OLE DB APIs the metadata information about the view, instead of the base table or tables, when browse-mode metadata is being requested for a query that references the view. Browse-mode metadata is additional metadata returned by SQL Server to the client-side DB-LIB, ODBC, and OLE DB APIs, which allow the client-side APIs to implement updatable client-side cursors. Browse-mode meta data includes information about the base table that the columns in the result set belong to.
For views created with VIEW_METADATA option, the browse-mode meta data returns the view name as opposed to the base table names when describing columns from the view in the result set.
When a view is created WITH VIEW_METADATA, all its columns (except for timestamp) are updatable if the view has INSERT or UPDATE INSTEAD OF triggers. See Updatable Views later in this topic.
Т.е. скажите CREATE VIEW .... WITH VIEW_METADATA
и все дела. Можно ещё подвесить триггер UPDATE INSTEAD.
С уважением, МОА
← →
MOA (2002-05-07 13:45) [18]Прошу прощения, потерял из виду, что Вам нужен INSERT. К INSERT все вышесказанное тоже относится, ну и триггер, конечно же INSERT INSTEAD.
Удачи! МОА.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.05.30;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.005 c