18

このウィキの投稿では、問題と解決策の両方について概説しています。他の場所でこの問題を解決するための具体的なものが見つからなかったので、同様の問題を抱えている可能性のある他の人のためにこれを投稿したいと思いました。

最近、SQLServer2000データベースをSQLServer2005にアップグレードしました。サーバー上のデータベースの1つは、MSAccessデータベースへのバックエンドです。MS Accessデータベースは、DSNレスODBCを介したパススルークエリを使用してSQLServerに接続します。

DSNなしの接続文字列の例を以下に示します。

ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
    Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
    Trusted_Connection=Yes

アップグレード後、ユーザーがパススルークエリを実行できず、次のエラーが表示されていたことがわかりました。

ODBC-「SQLServer」への接続に失敗しました

SQLサーバーログインの特権をsysadminサーバーの役割に昇格させると問題が軽減されたため、これは最初はアクセス許可の問題であるように見えました（ただし、これは明らかに優れた解決策ではありません）。

ログインをsysadminロールから戻した後、ManagementStudioを介してSQLServerに接続すると、ログインでストアドプロシージャが実行される可能性があることがわかりました。まったく同じログインは、MSAccess内からはできませんでした。これは、アクセス許可の問題ではなく、ストアドプロシージャを実行しようとしているときにMSAccessが実行していたことを示しています。

Profilerを使用してサーバー上でトレースを実行したところ、ストアドプロシージャの実行前にMSAccessが次のコマンドを実行しようとしていることがわかりました。

DBCC TRACEON(208)

ストアドプロシージャを実行する前に、このコマンドで失敗したようです。Webでの調査によると、DBCC TRACEON（208）は「SETQUOTED IDENTIFIERS ON」コマンドを使用するのと同等であり、SQL2005ではこのDBCCコマンドを実行する権限が取り消されていました。

さらに調査した結果、MSクエリへの参照にも同様の問題があり、接続文字列のAPPコンポーネントを「MSクエリ」から別のコンポーネントに変更する必要があることがわかりました。

すぐに、ODBC接続文字列のAPPコンポーネントを変更し、MSAccessはストアドプロシージャの実行前にDBCCTRACEON（208）を実行しようとしなくなりました。

さらにテストした後、APPコンポーネントに含まれている「著作権」記号まで問題を追跡しました。

APP=Microsoft® Access (Pass Through Query)

著作権記号を削除することで、すべてが接続に問題なく機能し、アプリケーションは以前のSQL2000で行っていたように機能しました。

これが同様の問題を抱えている他の人の助けになることを願っています。

4

1 に答える 1

1

それは登録商標記号ではありませんか？

odbcベースの攻撃に対するSQLServer2005の防御の1つに当たったと思います。インターネット上には何もないので、MSが内部で処理したものである可能性があります。

于 2009-09-03T05:24:07.817 に答える