ESQL 式でストリング関数を使用する場合、特定のパラメーターは文字位置やカウントを参照します。
SUBSTRING('Hello World!' FROM 7 FOR 4)
Worl というストリングが結果として得られます。これは、7 が 7 番目の文字位置を参照し、4 は 4 文字を参照しているからです。Hello World! というストリングが ASCII コード・ページで表現されている場合、その表記の 7 番目のバイト は、7 番目の文字です。 しかし、他のコード・ページやエンコード・スキーム (例えば、Unicode 表記のあるもの) では、7 番目の文字が第 13 バイトから始まり、4 文字が 8 バイトを占める場合があります。
WebSphere® Message Broker は、こうした状態を正しく処理します。 つまり、数値パラメーターおよびこれらのストリング関数の結果が、それらを表記するのに使用されているバイトではなく、常に文字 を参照するようにします。
WebSphere Message Broker が、データベース・エンジンに式の処理を代行させる場合があります。 例えば、データベース・データ・ソースに適用された SELECT 関数に WHERE 節がある場合、式中のすべての関数を解釈できるなら、データベースに WHERE 節が渡されます。
データベースがサポートしない関数がある場合、WebSphere Message Broker は、式のうちの解釈できる部分のみを渡し、フィルター処理されていないレコード・セットを取得し、残りのフィルタリングをそれ自身で実行します。
DB2® ストリング関数は文字 インデックス付けではなく、バイト・インデックス付けを使用します。 したがって、Unicode データの場合に、特定の関数の意味が (それらを「解釈」できるとしても) WebSphere Message Broker 関数と違ってきます。
例えば、Unicode UTF8 表記の文字は、1 バイトから 4 バイトまでを占める場合があるので、7 番目の文字は第 7 バイトから第 25 バイトまでのいずれかから始まる可能性があります。
これらの関数は、ストリング中の文字のインデックスまたはカウントを参照する、数値パラメーターを取るか、または数値結果を返すものです。
これらの関数を含む式が DB2 データベースに渡され、Unicode ストリング・データがデータベース中で処理されると、予期しない結果になったり、エラーが発生したりする可能性があります。
また、例えば PASSTHRU 関数を使ってこのようなタイプの式がデータベースに直接渡される場合にも、このエラーが発生する可能性があります。 このような場合、必要に応じて各々の式をターゲット・データベース用に自分で変更することができます。
この問題を避けるために、式を組織的に変更することはできませんし、WebSphere Message Broker もそのようにはしません。
UTF8 表記で複数バイトを占める文字が Unicode ストリングでまったく使用されていなければ、関数は正しく実行されます。