0

現在、すべての本番データベースをSQL Server200532ビットインスタンスから新しいSQLServer201264ビットインスタンスに移行しています。

開発者がまだ苦しんでいる主な問題の1つは、リンクサーバーです。

テキスト、csv、またはexcelファイルからデータを取得する必要のあるプログラムがたくさんあります。その実装方法は、サーバーをテキストファイルにリンクすることで、selectステートメントをテキストファイルに簡単にスローして挿入できます。テーブル。

問題は、32ビットサーバーMicrosoft.Jet.OLEDB.4.0がすべてのユーザーに対して完全なアクセス許可を持っているせん断されたディレクトリ上のファイルをドライバーに使用し、セキュリティの問題に遭遇することはなかったことを引き起こしました。

新しい64ビットサーバーに、次の構文のリンクサーバーを追加しました。

USE [master]
GO
EXEC master.dbo.sp_addlinkedserver 
    @server = N'TEMP_FILES_1'
    , @srvproduct=N''
    , @provider=N'Microsoft.ACE.OLEDB.12.0'
    , @datasrc=N'\\SERVER-APP01\BWA\TempFiles'
    , @provstr=N'Text'

ノート：

  • データソースはネットワーク共有上にあります。
  • MSSQLサービスは、ドメイン管理者アカウントとして実行されます。
  • 私はドメイン管理者としてリモートでログインしていますが、これはもちろんローカル管理者でもあります。
  • \\SERVER-APP01\BWA\TempFilesディレクトリには、すべての人にフルアクセスが設定されています。

実行するEXEC sp_testlinkedserver [TEMP_FILES_1]と、次のエラーメッセージが表示されます。

OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "TEMP_FILES_1" returned message "'\\SERVER-APP01\BWA\TempFiles' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides.".

これは間違いなくセキュリティの問題ですが、面白いのは、実行するxp_cmdshell 'dir \\SERVER-APP01\BWA\TempFiles'とレコードが返されるため、サービスがこのフォルダにアクセスできることです...

私のローカルコンピューターの反対側にも、同じリンクサーバーを持つ64ビットインスタンスがあり、それは魅力のように機能します！

私は自分の問題の解決策を見つけるためにインターネットを這い回っていますが、テキストファイルにリンクされたサーバーは特に64ビットではほとんど使用されていないようです。

4

1 に答える 1

0

以下のように、データを読み取る前に、ファイルを宛先 SQL Server システムのドライブにコピーする必要がありました。

EXEC xp_cmdshell 'net use y: \\[source directory path] [pw] /USER:[active user]'
EXEC xp_cmdshell 'copy y:\[source file] [destination directory]'
EXEC xp_cmdshell 'net use y: /delete'
于 2017-01-24T15:48:00.690 に答える