このwikiのポストは、問題と解決の両方を概説しています。他の場所でこの問題を解決するための具体的な方法を見つけることができなかったので、同様の問題を抱えている可能性がある他の人にもこれを投稿したかったのです。SQL 2000のODBCの問題 - > 2005のアップグレード
最近SQL Server 2000データベースをSQL Server 2005にアップグレードしました。サーバー上のデータベースの1つは、MS Accessデータベースのバックエンドです。 MS Accessデータベースはパススルークエリを使用し、DSNレスのODBCを介してSQL Serverに接続します。
DSNレス接続文字列の例を以下に示します。
ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
Trusted_Connection=Yes
をアップグレードした後、我々はユーザーがパススルークエリを実行することができませんでしたし、次のエラーが表示なっていたことがわかりました。
ODBC - 'SQL Serverの ' への接続は、これが最初であるように思われ
を失敗しましたSQL Serverログインの権限をsysadminサーバーの役割に昇格させると、問題が緩和されるため(ただし、これはすばらしい解決策ではありません)
sysadminロールからログインした後、Management Studio経由でSQL Serverに接続すると、ログインによってストアドプロシージャが実行されることがわかりました。非常に同じログインは、MS Accessからできませんでした。これは、アクセス権の問題ではなく、ストアドプロシージャの実行中にMS Accessがやっていたことを指摘していました。
私たちは、プロファイラを使用して、サーバー上のトレースを実行しましたが、これは以前のストアドプロシージャの実行には、次のコマンドを実行しようとしているのMS Accessを示した:
DBCC TRACEON(208)
前に保存するには、このコマンドで失敗に見えましたプロシージャ実行。 DBCC TRACEON(208)が 'SET QUOTED IDENTIFIERS ON'コマンドを使用するのと同等であること、そしてこのDBCCコマンドを実行するためのSQL 2005 priveledgesが廃止されていることをWebで調べました。
さらに調査したところ、同様の問題を抱えるMS Queryへの参照があり、接続文字列のAPPコンポーネントを 'MS Query'から別のものに変更する必要がありました。
慌てて、ODBC接続文字列のAPPコンポーネントを変更しました。ストアドプロシージャの実行に先立ってMS AccessはDBCC TRACEON(208)を実行しようとしなくなりました。
さらにテストの後、我々はAPPコンポーネントに含ま「著作権」記号にまで問題を追跡:
APP=Microsoft® Access (Pass Through Query)
を著作権記号を除去することにより、すべての接続でうまくだったし、アプリケーションがそれとして働いていたが以前はSQL 2000で行っていました。
これは、これと同様の問題を抱えている他の人に役立ちます。
これをトラブルシューティングして投稿するのに優れた仕事です。この問題が最初に起こったときよりも、髪が少なくなっていると思います... –
これを共有してくれてありがとう。それを質問と答えに分けることができますか?それはより良いSOデザインに役立ちます。 –
これは回答ですか?もしそうなら、それに印を付けてください! – djangofan