1

私たちのWebアプリケーションは、UTF-8でエンコードされたデータをVARCHARフィールドに格納します。最近、DataDirectのOpenAccessODBCドライバーを使用してODBC経由でこのデータにアクセスできるようになりました。これは、DataDirectのOpenAccess SDKを使用して実現され、サービスとインターフェイスするC＃.Netクラスを記述します。お客様はSELECTクエリのみを実行できます。また、現時点では結果を100K行に制限しています。

このソリューションは、このエンコードされたデータの一部を使用してフィールドをクエリすることは、当然のことながら、ユーザーにはぎこちないように見えることを除いて、実際にうまく機能します。私たちのサービスの次のリリースでは、エンコードされていない文字列を使用してクエリを実行し、その後エンコードされていない結果を表示する機能をユーザーに提供したいと思います。

着信クエリをUTF-8でエンコードし、VARCHARフィールドにフラグを付けてエンコードされていない結果を返すことでこれを解決しました。これはWVARCHARでした。これは実際に非常にうまく機能しています。ただし、Unicode文字が存在する（または存在しない）にもかかわらず、すべてのVARCHAR列がWVARCHARとして返されることを意味します。

現時点では、多くのお客様が独自のSQL ServerインスタンスでSSMSにリンクサーバーを作成する方法を採用しており、これが私の推奨する接続方法です。サービスでは結果が100K行に制限されているため、OPENQUERYを使用してクエリを実行することをお勧めします。ただし、SSMSのリンクサーバーの構成に不足しているものがあるようです。これらのWVARCHAR列に対して文字列関数（LEFT、RIGHT、SUBSTRINGなど）を実行すると、SSMSは次のエラーを返します。

リンクサーバー「LOCAL」のOLEDBプロバイダー「MSDASQL」は、「要求された変換はサポートされていません。」というメッセージを返しました。メッセージ7341、レベル16、状態2、行1リンクサーバー「LOCAL」のOLEDBプロバイダー「MSDASQL」から列「[MSDASQL].ColName」の現在の行の値を取得できません。

これは、次のようなクエリに対して返されます。

SELECT *
FROM OPENQUERY([LOCAL], '
  SELECT LEFT(FirstName, 2) AS ColName
  FROM dbo.User 
')

このクエリから関数を削除するLEFTと、FirstName列が返され、エラーなしで適切にデコードされます。

この問題は、たとえばMSExcelのクエリには影響しません。また、表面的には、DataDirect製品にインターフェイスする.Netクラスをデバッグするときに、文字列はそれぞれの機能によって適切に影響を受けるように見えます。リンクサーバーのプロパティですべてのサーバーオプションを変更しようとしましたが、適切な組み合わせを見つけることができませんでした。ここで吠えるのにぴったりの木を探しています。結果をWVARCHARに変更して処理するのですか？それとも、SSMSリンクサーバーの属性を変更する必要があるのでしょうか。

4

1 に答える 1

1

リンク サーバーのプロパティで、COLLATION COMPATIBLE を TRUE に設定すると、問題が解決されます。

于 2013-01-08T16:50:47.700 に答える