Mac De Oracle Heterogeneous! #63 Tweet

続きです。Generic Connectivity経由でPostgreSQL7.4.9の文字型にアクセス　最終回のつづき（なんじゃそりゃ）。

＝＝＝＝＝＝＝＝＝まとめ＝＝＝＝＝＝＝

利用しているODBC driverはこちらで解説しているドライバー

Generic Connectivityの文字型マッピング
PostgreSQL7.4.9	Oracle10g R1	Generic Connectivityでの利用	備　考
char型	char型	△	PostgreSQLでのchar型の定義とODBCデータソースのvarchar型最大サイズの設定によりマップされる型が異なる。 char(n)の n が、ODBC データソースの設定でVARCHAR型最大サイズ以下である場合、char型にマップされる。 ただし、本テストでは、n=1024でvarchar2型にマップされた。（２５５〜１０２４のどの値でchar型からvarchar2型に切り替わるのかは未確認。単なるバグなのか？？）。 n ＞ ODBCデータソースの設定のVARCHRA型最大サイズである場合には、long型にマップされる。 また、Oracle側にマッピングされる際は、常にバイトセマンティクスとして解釈されるため、PostgreSQL側の文字型にマルチバイトが格納されている場合且つ、バイトサイズが　n を超える文字は切り捨てられる点に注意すること。そのような列をアクセスする必要がある場合には、PostgreSQL側の影響がなければ、PostgreSQL側の文字型の最大サイズを大きくすることで対応可能だろう。また、これも影響がないことが前提だが、text型に変更して文字の切り捨てを防ぐという方法も使えるかもしれないが、その場合、long型にマッピングされるので要注意。影響が大きくそのような対処ができないのならば、Generic Connectivityを利用せず、外部表を利用したり他の方法を考えたほうが無難。ストアドプロシージャを利用して解決する方法もあるかもしれないが未確認である。
	varchar2型	△
	long型	△
varchar型	varchar2型	△	PostgreSQLでのvarchar型の定義とODBCデータソースのvarchar型最大サイズの設定によりマップされる型が異なる。 varchar(n)の n が、ODBC データソースの設定でVARCHAR型最大サイズ以下である場合、varchar型にマップされる。 n ＞ ODBCデータソースの設定のVARCHRA型最大サイズである場合には、long型にマップされる。 また、Oracle側にマッピングされる際は、常にバイトセマンティクスとして解釈されるため、PostgreSQL側の文字型にマルチバイトが格納されている場合且つ、バイトサイズが　n を超える文字は切り捨てられる点に注意すること。そのような列をアクセスする必要がある場合には、PostgreSQL側の影響がなければ、PostgreSQL側の文字型の最大サイズを大きくすることで対応可能だろう。また、これも影響がないことが前提だが、text型に変更して文字の切り捨てを防ぐという方法も使えるかもしれないが、その場合、long型にマッピングされるので要注意。影響が大きくそのような対処ができないのならば、Generic Connectivityを利用せず、外部表を利用したり他の方法を考えたほうが無難。ストアドプロシージャを利用して解決する方法もあるかもしれないが未確認である。
	long型	△
text型	long型	△	通常は、long型にマッピングされるが、ODBCデータソーソの設定で、「text型を長文字列として扱う」をチェックしなければ、varchar2型にマッピング（本当にマッピングされるか未確認。m(_ _)m ）される。
	varchar2型 （未確認）	△

ソート時の注意
PostgreSQLでは、空文字は、NULLとは区別されているが、Oracleは、空文字をNULLとして扱うので注意が必要である。例として検索時に、 where 列名 = ''　又は、 where 列名　!= ''と記述した場合、Oracleでは、　列名　= NULL 又は、列名　!= NULLと解釈され不定され正しい結果は得られない、　'' は利用せず、　列名　IS NULL又は、 列名 IS NOT NULLと書くべし。（Oracleを長年利用してきた方ならば間違うことはない事なのだが・・・）

次回、こんどこそ本当にMySQLの文字型にアクセスへつづく。