DBC.AccessRights内の行では、権限は、その権限が作成されたシステム領域の階層構造内のレベルに対応します。その結果、有効なREVOKE文を実行依頼しても、取消しが正しい階層レベルで要求されなかったために、指定した権限が取り消されない可能性があります。
例えば、オブジェクトに対する権限がデータベースまたはユーザー レベルで与えられた場合に、そのデータベースまたはユーザー領域内の特定のテーブルに対するこれらの権限を取り消すためにREVOKEリクエストを実行依頼すると、このリクエストはメッセージを返さずに完了しますが、指定されたデータベースまたはユーザーに関するテーブルとこれらの権限を対応させる行がないので、DBC.AccessRightsから行は削除されません。その代わりに、テーブルを含むユーザーまたはデータベースとこれらの権限を対応させている行がDBC.AccessRights内にあります。
以下の領域の階層構造について考えてみましょう。
ユーザーpayrollがシステムにログオンし、pay_dbに対するSELECT権限をユーザーhuman_resourcesとそのすべての子孫に与えるとします。
BTEQ LOGONコマンドおよびGRANTリクエストは以下のようになります。
.LOGON tdpid/payroll,password GRANT SELECT ON pay_db TO ALL human_resources; Grant accepted.
その後ユーザーpayrollはデータベースtable_c内のpay_dbに対するSELECT権限をhuman_resourcesおよびその子孫から取り消すことにしたとします。この権限を取り消すために、ユーザーpayrollは次のREVOKEリクエストの実行を依頼します。
REVOKE SELECT ON table_c FROM ALL human_resources; Revoke accepted.
Payrollは、table_cに対するSELECT権限がhuman_resourcesとその子孫から取り消されたと認識しているが、DBC.AccessRightsに対するSELECT権限をhuman_resourcesに与えている行がtable_c内にないので、取り消されていません。pay_dbデータベース全体に対するSELECT権限をhuman_resourcesに与える行がDBC.AccessRights内に残っているので、元々与えられていたSELECT権限として有効です。