概要
Cognos Analyticsは複数のデータソースをサポートしており、それぞれのデータソースに適したSQLを生成するようになっているため、通常はデータソースを意識することなくレポートを作成することができます。
しかし、例外的にデータソースの仕様に合わせたレポート作成が必要になる時があります。
この記事では、データソースのテキスト文字列の照合順序の仕様の違いによる課題と、Cognosのレポートの修正で回避できたケースを紹介します。
文字列比較の課題
データベースでの文字列比較には照合順序と呼ばれるルールがあり、データベースによってその設定が異なることがあります。
例えば、以下のドキュメントはSnowflakeの照合順序ですが、デフォルトの設定では文字列比較の際に先頭/末尾のスペース削除（スペーストリミング）は行われません。
https://docs.snowflake.com/ja/sql-reference/collation
これがCognos Analyticsのレポートで課題になるケースとしては、以下のようにプロンプトで検索条件をテキスト入力する場合、別のデータソースに移行したときに検索結果が出なくなることがあります。
select * from T where empid in (#promptmany('P_emp', '', "'NoSelect'")#)
プロンプトのテキスト入力時にExcelなどからコピーペーストする際に空白もしくは改行コードがそのまま入力されることがあります。
データベース側の照合順序の設定で、文字列比較の際にスペーストリミングが行われることで検索結果が正しく出力されていたものが、Snowflakeのようにデフォルトでスペーストリミングを行わないデータベースでは、文字列比較が不一致となり検索結果が出てこなくなるケースです。
回避策
最も望ましい解決策は、データベースの照合順序の設定でスペーストリミングが行われるようにすることですが、データベースの設定を変更できないケースでは、以下のようにCognosのマクロの記述で回避できることがあります。
select * from T where empid in (#promptmany('P_emp', 'token', "'NoSelect'")#)
promptmanyマクロのオプションは、以下のドキュメントを参照
https://www.ibm.com/docs/en/cognos-analytics/12.1.x?topic=macros-mandatory-optional-prompts
第二引数のDatatypeはデフォルトではstringですが、これをtokenにすることで空白が取り除かれた形でデータベースを検索できるようになりました。
まとめ
上記はあくまでも、データベースの設定が変更できずにCognosレポートの修正のみで回避したケースです。
この手法が正しいわけではなく、また常にうまく回避できるわけでもないので、あくまでも参考までです。