オブジェクトが存在するかどうかを判断するために、最初にそのユーザーとして sysobjects をクエリして、特定のユーザーに対して SQL でスキーマの変更を実行しようとするレガシー システムを使用しています。存在する場合は ALTER VIEW ステートメントを作成し、そうでない場合は CREATE VIEW ステートメントを作成します。この場合、ビューは存在しますが、クエリは引き続きオブジェクトの一覧表示に失敗します。
例えば：
setuser 'APPLICATION_DEV'
Select * from sysobjects o, sysusers u
where u.uid = o.uid
and u.name = N'APPLICATION_DEV'
問題は、このデータベース内の特定のアカウントがエラーなしでこのクエリを実行でき、そのユーザーが所有するすべてのオブジェクトを返すことです。ただし、他のアカウントは、このクエリによって返されるレコードを取得しません。ユーザーを SA に設定してクエリを実行すると、すべてのユーザー オブジェクトが表示されます。影響を受けるユーザーはスキーマの所有者であり、スキーマに対するビューの作成権限を持っています。作業中のユーザー アカウントと非作業中のユーザー アカウントの間で権限の違いを見つけることができません。
ユーザーがsysobjectsで自分のオブジェクトを照会することを制限する、私が見逃している権限はありますか?
はい、sysobjects が廃止されたことは承知していますが、ここで実際のコードを制御することはできず、代わりにデータベースを修正して、コードが期待どおりに機能するようにする必要があります。
編集：追加の調査結果。問題を複雑にするために、これを正常に実行できます。
setuser 'APPLICATION_DEV'
Select * from sysusers
Where name = 'APPLICATION_DEV'
これも正常に実行できます。
setuser 'APPLICATION_DEV'
Select * from sysobjects
Where uid = 308 --308 is the uid of the APPLICATION_DEV user
ただし、where 句または INNER JOIN を介して結合を使用すると、レコードが取得されません。純粋に結合に基づいてレコードへのアクセスを制限するものは何ですか? インデックスの権限?? 私は困惑しています。