1

ねえ、私はこれで髪を引っ張っています。

データベース サーバー (SQL Server 2000) とファイル システムの両方ですべてのアクセス許可をチェックし、実行しようとしていることが可能であることを確認しました。状況は次のとおりです。

会社のイントラネットの Tomcat サーバーで Java EE Web アプリケーションを実行しています。簡単に言うと、このアプリケーションは数値を計算し、パイプ区切りのレコード ファイルを作成してデータベースに BULK INSERT し、そのファイルを UNIX サーバーに保存します。

次に、xp_cmdshell を使用して UNIX から Windows SQL Server ボックスにファイルを FTP 送信し、ファイルを一括挿入するストアド プロシージャが呼び出されます。Management Studio からこのストアド プロシージャ (Web アプリを実行する tomcat ユーザーとしてログイン) を呼び出すと、エラーは 1 つも発生せず、FTP が転送され、ファイルが読み込まれます。

これは私を悪化させている部分です。

Java EE アプリがこのストアド プロシージャを呼び出すと、実際にはファイルを SQL Server ボックスに FTP 送信しますが、成功しても SQLServerException が発生します。韻や理由はありません。しかし...例外がスローされたとしても、私のファイルはサーバー上ですべて快適になります。

UNIX サーバーから xp_cmdshell を実行すると、SQL Server で問題が発生しますか (プログラムが実行しているのはストアド プロシージャの呼び出しだけなので、これはばかげているように聞こえますが、火曜日の夜の 11:55PM にまだオフィスにいます。ばかげていることは何もないと思います...）

どんな洞察も素晴らしいでしょう...

編集：

また、SQL プロファイラーを使用して SQL Server へのトラフィックを表示しています...そして、ストアド プロシージャを呼び出すために使用している実際のステートメントを確認できます。それをSQL Server Management Studioにコピーし、Tomcatユーザー資格情報を使用して実行すると、問題なく実行されます...

4

1 に答える 1

1

わお。これが、午後 11 時にコーディングするのが良くない理由です。

xp_cmdshell は、実行ごとに結果セットを返します。基本的に、コマンド プロンプトで表示されるのと同じように、コマンド ラインからの出力が得られます。ここで重要なのは結果セットです。

ストアド プロシージャを呼び出すために呼び出していた JDBC メソッドは issueUpdate() で、返された xp_cmdshell の結果セットで例外をスローしていました。issueQuery() に変更すると、例外は発生せず、残りのコードは完了するまで実行されました。

これをきれいにするためにやるべきことがいくつかあると思いますが、この解決策には満足しています。

于 2009-01-14T06:06:56.490 に答える