ネットワークロケーションを使用して一括読み込みするたびにこのエラーメッセージが表示されるユーザーがいますが、以下のエラーがスローされます。
「ファイルを開けなかったため、一括読み込みできません。オペレーティングシステムエラーコード3(このエラーのテキストを取得できませんでした。理由:15105)。」
ファイルの場所にFQDNが指定されている(\ servername\sharename\filename.txt)
ファイルがサーバー(C:\ドライブ)にコピーされると、クエリはSSMS経由で正常に実行されます
共有フォルダのすべてのNTFSアクセス許可を確認しました。私は解決策を提案する多数の投稿を経験しましたが、運はありませんでした。
winerror.hはオペレーティングシステムエラーコード3をリストします as ERROR_PATH_NOT_FOUND
。これはおそらく\\servername\sharename\filename.txt
が存在しないか、SQL ServerサービスアカウントがUNC経由でファイルにアクセスできません。
SQL Server構成マネージャーを使用して、SQL Serverサービスアカウントの名前を確認します。
UNCのFileshareセキュリティをチェックして、アカウントが共有にアクセスできることを確認します。 UNCの下にあるフォルダーのファイルシステムセキュリティをチェックして、アカウントがファイルにアクセスできることを確認します。
T-SQL BULK INSERT
には セキュリティアーキテクチャの理解 が必要です。そのページからの引用:
ユーザーがSQL Serverログインを使用する場合、SQL Serverプロセスアカウントのセキュリティプロファイルが使用されます。 SQL Server認証を使用したログインは、データベースエンジンの外部では認証できません。したがって、SQL Server認証を使用したログインによってBULK INSERTコマンドが開始されると、データへの接続は、SQL Serverプロセスアカウント(SQL Serverデータベースエンジンサービスによって使用されるアカウント)のセキュリティコンテキストを使用して行われます。ソースデータを正常に読み取るには、SQL Serverデータベースエンジンが使用するアカウントにソースデータへのアクセスを許可する必要があります。対照的に、SQL ServerユーザーがWindows認証を使用してログオンした場合、ユーザーは次のことができるファイルのみを読み取ることができます。 SQL Serverプロセスのセキュリティプロファイルに関係なく、ユーザーアカウントによってアクセスされます。
1台のコンピューターからsqlcmdまたはosqlを使用してBULK INSERTステートメントを実行し、2番目のコンピューターのSQL Serverにデータを挿入し、UNCパスを使用して3番目のコンピューターのdata_fileを指定すると、4861エラーが発生することがあります。
このエラーを解決するには、SQL Server認証を使用して、SQL Serverプロセスアカウントのセキュリティプロファイルを使用するSQL Serverログインを指定するか、Windowsを構成してセキュリティアカウントの委任を有効にします。ユーザーアカウントを委任に対して信頼できるようにする方法については、Windowsヘルプを参照してください。
とすれば:
ネットワーク上のファイルを使用するとエラーが発生する
エラーはnotがローカルファイル(SQL Serverを実行しているサーバーに対してローカル)を使用すると発生
エラーが発生notユーザーがリモートサーバーにログオンした場合にネットワーク上のファイルを使用すると発生する
私は言うでしょう:
ユーザーはWindowsログインで接続しています
ユーザーがSQL Serverログインで接続している場合、リモートサーバーからSQL Serverにログインした場合でも、リモートデスクトップ経由でサーバーから直接SQL Serverにログインした場合でも、動作は同じです。 SQL ServerログインはSQL Serverの外部(つまり、Windows/Active Directory)には存在しないため、なりすましの可能性があるセキュリティコンテキストはありません。その場合、BULK INSERT
/OPENROWSET(BULK...
プロセスは、SQL Serverプロセスを実行しているサービスアカウントの既存のセキュリティコンテキストを使用します。
Windowsログインで接続する場合、偽装できるセキュリティコンテキストが存在するため、一括操作はそれを実行しようとします。ここでの問題は、転送されたセキュリティトークンは、デフォルトでは再転送できないことです。これが、ユーザーがデスクトップから接続するときにエラーを受け取る理由です(ユーザーはデスクトップにログインしてセキュリティトークンを取得し、転送されたセキュリティトークンを使用してSQL Serverにリモートでログインします)。ユーザーがリモートデスクトップ経由でリモートサーバーに直接ログインすると、そのサーバーから完全なセキュリティトークンを取得し、それを使用してSQL Serverに直接接続するので、これを使用してネットワークサービスに転送できます。共有フォルダなど。
次のいずれかが必要です。
Everyone
またはDomain User
などの共有のアクセス許可を開く
Active Directoryに移動し、委任用にそのユーザーのWindowsログインを構成します。
(たぶん)EXECUTE AS
ステートメントのCREATE PROCEDURE
句を使用して偽装できるSQL Serverユーザーを設定し、一括操作を実行するストアドプロシージャを作成します。私はこれを試していないので、それがうまくいくかどうかは完全にはわかりませんが、アイデアは、セキュリティコンテキストをSQL Serverアカウントのセキュリティコンテキストに切り替えて、一括操作が偽装ではなく、現在の操作を使用するようにすることですSQL Serverサービスアカウントのセキュリティコンテキスト。おそらく、一撃の価値があるでしょう。