サーバーからの制約の処理
どのようなデータが有効かという制約がデータベース サーバーで定義されている場合、その制約をクライアント データセットで把握していると役立ちます。把握していれば、ユーザーの編集内容がサーバーの制約に違反しないことをクライアント データセットで保証できるからです。そうすれば、違反した内容をデータベース サーバーに渡して、サーバーで拒否されることがなくなります。つまり、更新処理中にエラーになることが減ります。
データのソースにかかわらず、明示的にクライアント データセットに追加することで、サーバー制約を複製することができます。この手順は、「データ値の制約」で説明しています。
ただし、サーバー制約が自動的にデータ パケットに含められれば、さらに便利です。そうすれば、デフォルトの式や制約を明示的に指定する必要がなくなり、クライアント データセットではサーバー制約が変化するとその値を変更できるからです。デフォルトでは、次のとおりに処理が行われます。ソース データセットがサーバー制約を把握している場合、プロバイダによりサーバー制約が自動的にデータ パケットに含められ、ユーザーが編集内容を変更ログに送信するときにクライアント データセットにより制約が適用されます。
メモ： サーバーから制約をインポートできるのは、BDE を使用しているデータセットだけです。つまり、TBDEClientDataSet または TClientDataSet を BDE ベースのデータセットを表すプロバイダと一緒に使用した場合にのみ、サーバー制約がデータ パケットに含められます。サーバー制約をインポートする方法およびプロバイダがサーバー制約をデータ パケットに含めないようにする方法の詳細は、「サーバー制約の処理」を参照してください。
メモ： インポート後の制約の扱い方の詳細は、「サーバー制約の使用」を参照してください。
サーバーの制約や式のインポートは非常に有用な機能であり、アプリケーションでデータ整合性を保つのに役立ちますが、一時的に制約を無効にしなければならない場合があります。たとえば、フィールドの現在の最大値に基づいてサーバー制約が設定されているけれども、クライアント データセットでインクリメンタルに取得を行っている場合には、クライアント データセットにおけるフィールドの現在の最大値がデータベース サーバーにおける最大値と異なるため、制約も異なるものになる可能性があります。あるいは、制約が有効であり、同時にクライアント データセットでレコードにフィルタを適用している場合、フィルタと制約条件とが意図せず衝突する可能性があります。どちらのケースでも、アプリケーションで制約のチェックを無効にすることができます。
一時的に制約を無効にするには、DisableConstraints メソッドを呼び出します。DisableConstraints を呼び出すたびに、参照カウントが 1 つ増えます。参照カウントがゼロより大きければ、クライアント データセットに対して制約は適用されません。
クライアント データセットの制約を再び有効にするには、データセットの EnableConstraints メソッドを呼び出します。EnableConstraints を呼び出すたびに、参照カウントが 1 つ減ります。参照カウントがゼロになると、制約は再び有効になります。
ヒント： 必要になれば制約を有効にできるよう、DisableConstraints と EnableConstraints は必ずペアのブロック内で呼び出してください。