iBatisがMS Accessデータベース(*.mdb)にアクセスする際の注意点


Accessデータベースの処理が必要なため、永続層スキームを考慮する際、効率的な理由からiBatisを最終的に選択するが、実行可能性スキームの試験過程で、いくつかの厄介な問題に遭遇し、このスキームを放棄するところだった.
1.iBatisのUpdateを実行する場合、Accessテーブルのプライマリ・キーが自増型プライマリ・キーである場合、すなわち「自動番号+ロング整数+インクリメント」型プライマリ・キーであり、対応するJavaBeanの属性値はint型のみであり、long型に設定できない場合、「java.sql.SQLException:[Microsoft][ODBC Microsoft Access Driver]オプションの機能が実現していない」と報告される

<update id="updateMsg"  parameterClass="msg">
		update MESSAGE set MESSAGE_TEXT=#text# where MESSAGE_ID=#msgID#
</update>

さらに,実質的にデータ型の不整合によるもの,すなわちJavaのint型がACCESSに対応するロング整数型であることが分かった.(ロングフォーム(既定値)-2114748648から2147483647(小数点なし)までの数値を保存します.4バイト).
どうやら、自分の経験が足りないようだが、iBatisのエラーヒントもぼんやりしていて、ソースコードの追跡デバッグを経て、半日でこの道理が分かった.
2.javaのdoubleタイプとAccessの二重精度と単精度のマッチング
3.Accessは、insert後にiBatisによってSqlMapによって取得されたプライマリ・キー列の文を自動的に生成します.

	<insert id="insertMsg" parameterClass="msg">
		insert into MESSAGE(
		MESSAGE_TEXT,
		PRICE)
		values(
		#text#,
		#price#)
		<selectKey resultClass="int" type="post" keyProperty="msgID" >  
        	select @@IDENTITY as [value]
    	</selectKey>  
 	</insert>

(1).postは、Accessが使用するコミット後にプライマリ・キーを生成する方法を示す.
(2).msgIDとは、テーブルのプライマリ・キー列がJavaBeansのどの属性に対応するかを意味します.
(3).注意「select@@IDENTITY as
[value]」の「value」は、ACCESSのキーワードであるため、カッコを付けるか、他の文字に変更する必要があります.これにより第4の注意事項が絡んでくる
4.SqlMapファイルでは、sql文で列名がACCESSのキーワードであれば、不可解な問題を引き起こす可能性があります.キーワードを列名として使用することをできるだけ避けるか、列名を中括弧で囲むことで解決します.