UDF は、データベースに損傷を与える恐れのない環境でデバッグすることが大切です。 UDF が正しいという確信が得られるまで、テスト・データベース・インスタンスでテストする必要があります。このことは、FENCED や NOT FENCED UDF にもあてはまります。これらのタイプはいずれも、正しく作成されていないと DB2 を誤動作させる可能性があるからです。 UDF を FENCED として定義したほうが、 NOT FENCED として定義するよりも保全性の維持や機密漏れからの保護が得られますが、確実な保証はありません。いずれにせよ、十分な検討やテストを重ねることを含め、ふさわしい仕方でコーディングすることが必要になります。
DB2 は、記憶域を誤って修正する特定の限られたタイプの処置があるかを検査します (たとえば、 UDF が、多すぎる文字をスクラッチパッドや結果のバッファーに移動する場合)。この場合、そうした誤動作が検出されると DB2 はエラー SQLCODE -450 (SQLSTATE 39501) を戻します。また DB2 は、UDF が異常終了して SQLCODE -430 (SQLSTATE 38503) を戻したり、ユーザーが UDF を中断して SQLCODE -431 (SQLSTATE 38504) を戻したりする場合に、秩序正しく終了するように設計されています。
FENCED UDF を選択している場合であっても、戻り値バッファーを何回も上書きすることは、 UDF と DB2 を異常終了させる原因になり得ます。バイトを戻り値バッファーに移動させる UDF を設計、コーディング、検討する際には十分な注意を払ってください。たとえば、移動前に移動の必要があるバイト数を計算する UDF を作成する場合には、特に注意してください。 C では、この役割を果たす関数として memcpy が使用されるのが一般的です。バイトを戻り値バッファーに移動させる UDF の場合には、境界ケース (余分な short 値や long 値) を綿密に調べてください。
機密保護とデータベースの保全性にとって、 UDF を DB2 に対していったんデバッグして定義してしまえば、 UDF の本体を保護することが大切です。これは特に、UDF が NOT FENCED として定義されている場合に重要です。誰かが (自分自身を含む) 不慮または故意に、デバッグされていないコードを使って使用可能な UDF を上書きすると、 UDF はデータベースが非分離の場合に、そのデータベースを破棄するか、あるいはデータベースを安全に保護できないと考えられます。
残念ながら、ソース・レベルのデバッガーを UDF で簡単に実行する方法はありません。それにはいくつかの理由があります。
UDF は、通常は stdout が意味を持たないバックグラウンド処理で実行されるため、 printf() などの有効なデバッグ・ツールは UDF のデバッグには役立たないことに注意してください。 printf() を使用する代わりに、UDF にファイル出力論理を備えたり、デバッグする目的で表示データおよび制御情報をファイルに書き込むことができます。
UDF をデバッグするその他の技法は、ドライバーのプログラムを記述して UDF をデータベース環境の外側に呼び出す方法です。この技法を使うと、欄外に書いたか誤った全種類の入力引き数を使って UDF を呼び出し、それを不正に実行させることができます。この環境では、 printf() またはソース・レベルのデバッガーを使用することは問題ではありません。