#10СОВЕТ
По материалам статьи Dianne Siebold от 14 июля 2000г.
Dsiebold@earthlink.net
Вы можете использовать в запросе функцию GETDATE (), которая
возвращает текущую дату и время.
SELECT GETDATE () AS CurrentDateTime
CurrentDateTime
---------------------------
28 июль 2000 11:26
(1 row(s) affected)
Если функция GETDATE () возвращает дату в не удобном формате,
Вы можете изменить запрос, например, так:
SELECT (DATENAME(dd, GETDATE()) + " " +
DATENAME(month, GETDATE()) + " " +
DATENAME(yy, GETDATE()) + "г. " +
DATENAME(hh, GETDATE()) + ":" +
DATENAME(mi, GETDATE()))
AS CurrentDateTime
CurrentDateTime
---------------------------
28 Июль 2000г.11:27
(1 row(s) affected)
ГОТОВИМСЯ К ТЕСТУ ПО 1139AШПАРГАЛКА #3 продолжение (обзор официального курса Microsoft)
Как установить разрешения доступа к объектам SQLS7 ролям и
пользователям:
Учe:тным записям подключения пользователей, которые успешно
подключились к SQLS7 и которым сопоставлены учe:тные записи
пользователей сервера БД или роли, для успешной работы необходимо
получить разрешение на доступ и работу с объектами баз данных SQLS7.
Для каждой базы разрешения свои и могут быть трe:х типов:
предопределe:нные (для фиксированных ролей и владельцев, не подлежат
изменению), объектные (доступ к объектам БД и функциям их создания,
изменения, просмотра и удаления), операторные (доступ к операторам
создающим: базы, таблицы, представления, процедуры, правила,
определения, и резервирующим объекты БД). Само разрешение
подразумевает три состояния: предоставлено (GRANT), запрещено (DENY)
и отозвано (REVOKE). По умолчанию, до явного определения разрешения
пользователю, оно находится в отозванном состоянии и запись о нe:м
хранится в таблице sysprotects. Отозванное разрешение, в силу своей
аддитивности, может быть переопределено назначенной ролью, а
запрещение переопределить невозможно.
Для некоторых фиксированных ролей заранее предопределены разрешения,
и устанавливать их нет необходимости. Например, для роли sysadmin
автоматически наследуются абсолютно все разрешения, и поделать с этим
ничего нельзя. Кроме того, некоторые предопределe:нные разрешения
присущие этой роли невозможно применить к обычным учe:тным записям.
Схожий механизм действия предопределe:нных разрешений используют и
владельцы объектов, только безграничные разрешения предоставляются
им на область их владений.
Разрешения для обычных пользователей могут регулироваться на уровне
объектов и операторов. Чe:тко представляя себе границы прав каждого
пользователя, Вы можете установить им разрешения/запрещения на работу
с таблицами, столбцами или хранимыми процедурами, а также на возможность
использования операторов для создания баз или их элементов. Причe:м
разрешения на операторы применяются не к объекту, на который он
воздействует, а к самому оператору. Т.е. права на сам объект
(например, БД) у пользователя могут быть сколь угодно большие, но
некоторые операторы, воздействующие на этот объект, Вы можете ему
запретить использовать. Помните только, что устанавливать разрешения
на операторы могут только sysadmin, db_owner и db_securityadmin.
Разрешение на выполнение хранимых процедур сводится, в конечном итоге,
к разрешению на выполнение оператора EXECUTE. Правда, часто этого
бывает недостаточно, если пользователь не обладает необходимыми
объектными разрешениями. Объектные разрешения позволяют Вам тонко
регулировать прав доступа к данным и процедурам их обработки. Вы
можете предоставлять разрешения на целые таблицы и представления,
а также к отдельным столбцам. Важно только помнить некоторые правила,
которые проистекают из внутренней природы обработчика запросов T-SQL.
Например, устанавливая разрешения на таблицы и представления, Вы
регулируете права доступа пользователей к применению операторов UPDATE,
DELETE, INSERT и SELECT, но должны помнить, что возможность применения
пользователем БД предложения WHERE в операторах потребует предоставления
ему таких разрешений, что бы он мог выполнять операторы UPDATE и SELECT.
Другой пример относится к разрешениям на столбцы. Вы можете регулировать
применение пользователем операторов UPDATE, SELECT и REFERENCES к
конкретному столбцу, но когда пользователь попытается добавить строку
в таблицу, подчиняющуюся ограничению FOREIGN KEY, выяснится, что
пользователь должен обладать разрешениями для этого столбца для
выполнения операторов SELECT или REFERENCES.
Для предоставления разрешений пользователям удобно воспользоваться
SQL SEM или оператором GRANT. Для запрещения пользователю неких прав
применяется оператор DENY. С помощью оператора REVOKE можно удалить
заданные до этого разрешения или снять запрет. Это бывает удобно, когда
вы переводите пользователей в новую групп и собираетесь, в силу
аддитивности, делегировать разрешения и запрещения пользователям,
устанавливая их для группы.
Продолжение следует.
РАБОТА ДЛЯ DBA (ТОЛЬКО ПОШЛИТЕ РЕЗЮМЕ)
POSITION ID: DK-_ME_2 EMAIL: beri.evans@sullivancogliano.com
WEB: http://www.sulcog.com
POSITION ID: 193 EMAIL: recruiter@prairieinc.com
POSITION ID: 505-001222 EMAIL: ccastill@modisit.comSCResumes@modisit.com
WEB: http://www.modisit.com
POSITION ID: D-3135 EMAIL: khibbs@prodx.com
WEB: http://www.prodx.com
POSITION ID: 834 EMAIL: psheth@ecalyx.com
WEB: http://www.ecalyx.com
POSITION ID: FB0726-01 EMAIL: dave@goodshark.com
WEB: http://www.goodshark.com
POSITION ID: 181390 EMAIL: careers@ragingmouse.com
WEB: http://www.ragingmouse.com
POSITION ID: IMO35272 EMAIL: npeleuses@intellimark-it.com
WEB: http://www.intellimark-it.com