1

各ユーザーが FindResults というスキーマにテーブルを持っているデータベースで作業しています

例: MyDatabase.User1.FindResults、MyDatabase.User2.FindResults など。

ユーザーの 1 人としてログインしているときに、このテーブルで SELECT クエリを実行すると、問題なく動作します。ただし、このテーブルで SELECT クエリを実行しようとするストアド プロシージャ (MyDatabase.dbo.ReadFindResults) がありますが、MyDatabase.dbo.FindResults (存在しない) を読み取ろうとするため失敗します。動的 SQL を使用してこれを回避しましたが、これを回避する方法があることを望んでいました。

現在のユーザーのスキーマを使用するようにストアド プロシージャに指示する方法、またはスコープを変更して必要なテーブルを見つけられるようにする方法はありますか?

編集：ストアドプロシージャのコードは次のとおりです

-- Returns the IDs contained in the given find results set
CREATE PROCEDURE [dbo].[ReadFindResults]
    @resultsid int  -- The ID of the results set
AS
BEGIN

   SELECT objectid FROM FindResults WHERE resultsid = @resultsid

END
GO
4

2 に答える 2

0

次のような動的 SQL を使用できます。

DECLARE @sql NVARCHAR(1024) = "SELECT something FROM [userName].someTable"
DECLARE @userName NVARCHAR(255) = SUSER_SNAME()
SET @sql = REPLACE(@sql, "[userName]", @userName)

EXEC sp_executesql @sql

それもまた、そのクエリを実行するハキーな方法です。動的 SQL の詳細については、http: //www.sommarskog.se/dynamic_sql.htmlを参照してください。

私は今家にいて、SQL Server にアクセスできません。必要に応じて、仕事中の午前中に投稿を編集します。

于 2013-10-09T17:37:31.283 に答える
0

ストアド プロシージャでは、次のように言うことができます。

SELECT cols FROM MyDatabase..FindResults;

(スキーマ名は省きます。)

ただし、これは非常にエラーが発生しやすいようです。私見では、スキーマにバインドされた別のストアド プロシージャも用意するか、行が誰であるかを示す列を持つ単一のテーブルを用意する必要があります。

ハッキングは、ユーザー名として実行することである可能性があります:

DECLARE @sql NVARCHAR(255) = N'EXECUTE AS USER = N''' + SUSER_SNAME() + '''';
EXEC sp_executesql @sql;
SELECT whatever FROM Findresults;

しかし、私はこれをテストする機会がありませんでした (とにかく、シナリオでテストする準備ができています)。

そもそも、それは依然として非常に回避可能な問題のように思えますが、それは私だけかもしれません。

于 2013-03-29T21:49:59.027 に答える