Ultra Light J を除くすべての Mobile Link クライアントは、ダウンロードをリモート・データベースに組み込むときに参照整合性を確保します。
参照整合性に違反するローがあった場合、デフォルトでは、Mobile Link クライアントはダウンロード・トランザクションを失敗させずに、参照整合性に違反するすべてのローを自動的に削除します。
この機能には次のような利点があります。
同期スクリプトの間違いから保護します。スクリプトに柔軟性があると、リモート・データベースの整合性をそこなうローを誤ってダウンロードしてしまうことがあります。Mobile Link クライアントは、介入を要求せずに参照整合性を自動的に管理します。
この参照整合性のメカニズムを使用して、リモート・データベースから情報を効率的に削除できます。親レコードに削除データを送信するだけで、Mobile Link クライアントはすべての子レコードを自動的に削除します。これにより、Mobile Link がリモート・データベースに送信するトラフィックの量を大幅に減らすことができます。
Mobile Link クライアントは、参照整合性を維持するためにローを明示的に削除する必要がある場合、次のような通知を行います。
SQL Anywhere クライアントの場合は、dbmlsync によってログにエントリが書き込まれます。dbmlsync イベント・フックも使用できます。次の項を参照してください。
Ultra Light クライアントの場合は、SQLE_ROW_DELETED_TO_MAINTAIN_REFERENTIAL_INTEGRITY 警告が発生します。この警告には、テーブル名のパラメータが含まれます。参照整合性を維持するため、削除されるすべてのローで警告が発生します。同期をそのまま進める場合は、警告を無視してかまいません。警告を明示的に処理する場合は、エラー・コールバック関数を使用して警告をトラップします。さらに、削除されたローの数を取得することもできます。
警告が発生したときに同期を失敗させるには、同期 observer を実装し、observer に (グローバル変数などを使用して) エラー・コールバック関数から信号を送信する必要があります。この場合、同期は observer への次回の呼び出しで失敗します。
Mobile Link クライアントは、1 つのトランザクション内のダウンロードから変更を組み込みます。柔軟性をより向上させるために、参照整合性のチェックはこのトランザクションの終了時に行われます。チェックが遅いため、参照整合性に違反する状態を一時的にパスすることがあります。しかし、参照整合性に違反するローは、ダウンロードがコミットされる前に自動的に削除されます。
Ultra Light 販売アプリケーションに、次の 2 つのテーブルが含まれているとします。1 つのテーブルには、販売注文が含まれています。もう 1 つのテーブルには、各注文で販売された商品情報が含まれています。この 2 つのテーブルは、次のような関係です。
1 つの注文を削除するために sales_order テーブルに download_delete_cursor を使用すると、削除された受注を示す sales_order_items テーブルのすべてのローが、デフォルトの参照整合性メカニズムによって自動的に削除されます。
この方法には、次のような利点があります。
sales_order_items テーブルからのローは自動的に削除されるので、sales_order_items テーブル・スクリプトは必要ありません。
同期の効率が向上します。sales_order_items テーブルから削除するローをダウンロードする必要がありません。各販売注文に項目がたくさんある場合は、ダウンロードが小さくなるのでパフォーマンスが向上します。この方法は、速度の遅い通信方法を使用しているときに特に役立ちます。
SQL Anywhere クライアントの場合は、sp_hook_dbmlsync_download_ri_violation クライアント・イベント・フックを使用して、参照整合性違反を処理できます。Dbmlsync も、ログにエントリを書き込みます。
次の項を参照してください。
| Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |