2016-05-29 14 views
-1

私のプロジェクトでは、いくつかの手順で非常に奇妙な状況に陥っています。どちらも同じです(下記参照)が、異なるテーブルでは、問題を説明します(両方の手順で同じです)。MySql例外エラーコード:1366.不正な文字列値: ' xF0K xF59 {z ...'

クライアントに返す必要のある数百のラベルをホストするテーブルがあります。応答は常にTEXTとして送信されます。最初に、プロシージャは関連テーブルから選択し、必要な連結を実行し、その文字列を戻します。

私は、結果をDIGESTテーブルに格納する簡単な(あるいは考えた)変更を行いました。したがって、同じ関数が2回目に呼び出されると、まず、ダイジェストテーブル内で使用可能な応答があるかどうかをチェックし、そうであれば応答を返します。ダイジェストに一致するエントリがない場合は、レスポンスを作成し、ダイジェストテーブル内に格納して(次の呼び出しのため)、ビルドされたレスポンスを返します。

私は常にレスポンスをビルド(連結)して返すと機能は完璧に機能します。一方、ダイジェストテーブルから応答を抽出すると、エラーエラーコード:1366が返されます。不正な文字列値: '\ xF0K \ xF59 {z ...'

ダイジェストテーブルの内容を確認しても問題ありません。

問題の原因が考えられますか?

ご意見ありがとうございます。

+0

私は、他の6つの関数と全く同じメカニズムを使用していることを付け加えてください。優れたパフォーマンスで完璧に動作します。 – FDavidov

+0

これはあなたを助けるかもしれません[あなた](http://stackoverflow.com/a/1168099/2451726) – Arulkumar

+0

ありがとう@アーククマール、しかしそれはありません。私は、異なるソーステーブルで動作することを除いて、同一のロジックを実行する約8つの関数を持っています。 2つのPROBLEMATIC関数と唯一の違いは、返されるデータのサイズ(問題のある関数で最大)です。さらに、検索された文字列が英語(すなわち、実際には使用されていないUTFx)である場合、問題がポップします。 – FDavidov

答えて

0

私は運が良かったと判明しました(私が使っているバージョンの)既知のバグを打ちました。長いCLOBを一連のVARCHAR(テーブルの列の型を変更したもの)にチョッピングすることで解決しました。はい、私は知っている..これはパフォーマンスの点で最高の解決策ではありませんが、プロジェクトのこの段階では、データベースの新しいバージョンにアップグレードすることは考えません。

関連する問題