この特集のトップページへ
＞
Chapter 7：プレゼンテーション層の構築
7.4.5 顧客の削除と復帰
顧客の新規作成と編集の処理を実装したところで，次に顧客の削除と復帰の機能を実装してゆく。
顧客の削除と復帰はさして難しい処理ではない。削除のときにはBusiness.CustomerコンポーネントのDeleteCustomerメソッドを，復帰のときにはUndeleteCustomerメソッドを，それぞれ呼び出すだけの話である。
●顧客の削除ではまず，顧客の削除から説明する。Fig.7-16に示したように［削除］ボタンにはBTN_DELETEという名前を付けた。よって，ボタンが押されたときのClickイベントに対応するには，BTN_DELETE_Clickプロシージャを記述すればよい。実際に記述したものがList 7-29である。
List 7-29は少々長い。しかし，その大半は，顧客を削除したあとでマーキーの位置を設定し直すための処理である。実際に顧客を削除しているのは，35行目と36行目の2行だけにすぎない。
まず，8行目では，MsgBox関数を使い，本当にこの顧客を削除してよいかどうかを確認する処理をしている。Fig.7-35に示すとおり，表示されるメッセージボックスは［はい］と［いいえ］の2つのボタンを持つものである。ユーザーが［はい］ボタンを押したときには9〜46行目が実行され，顧客が削除されるという具合である。
10行目では削除対象となる顧客のDELETEDFLAGフィールドの値を，13行目ではIDフィールドの値（顧客番号）を，それぞれ取得する。そしてそののち，16〜26行目において，削除後にカレント行を合わせたい顧客のIDフィールドの値を取得するという処理をしている。
顧客を削除するビジネスロジックは，最初DELETEDFLAGフィールドをTrueにして削除ずみにし，2回目に削除されたときにレコードそのものを削除する，という2段階の削除操作をするように実装した。そして，AllAdminロールまたはSalesAdminロールに属するユーザーは，削除ずみのレコードも参照できるようにした。
17行目では，ユーザーがAllAdminロールまたはSalesAdminロールに属していて，かつ，削除対象となるレコードのDELETEDFLAGフィールドの値がFalseであるかどうかを確認している。AllAdminロールまたはSalesAdminロールに属していて，かつDELETEDFLAGフィールドの値がFalseであるレコードを削除しようとした場合には，そのレコードのDELETEDFLAGフィールドの値がTrueになるだけで，データグリッド上の表示は変わらない。そのため，削除後のデータグリッドでは，削除の対象となっている顧客をマーキーが指すように設定し直せばよいだろう。その処理が21行目で，beforeCustomerID変数に削除対象となっている顧客のIDフィールドの値を保存している。
一方それ以外の場合には，削除後には削除されたレコードはデータグリッドから見えなくなる。よって，削除後に削除対象となっている顧客にマーキーを合わせることはできない。そこで，24〜25行目にあるように，削除対象となっている行の次の行に表示されている顧客のIDフィールドの値をbeforeCustomerID変数に格納するようにした。
36行目にあるDeleteCustomerメソッドの呼び出しによって，対象となっている顧客が削除される。その後，39行目でデータグリッドの内容を更新し，それから43〜44行目において，16〜26行目の処理でbeforeCustomerID変数に格納しておいた値をIDフィールドの値として持つレコードを検索している。これにより，削除後のマーキーの位置が設定されるということになる。
少々ややこしいが，List 7-29でやっていることは，削除するときに，削除対象となるレコードがデータグリッドから消えないのであれば，削除対象となるレコードをマーキーが指すようにし，消えるのであれば，その次の行をマーキーが指すようにする，という処理をしているにすぎない。
なお，当然のことだが，削除対象となるレコードが消え，かつ，その次となるレコードが存在しないときには，この処理は失敗する。そのような場合には，25行目において実行時エラーが発生するが，On Error Resume Nextステートメントを使っているので，それは無視され，28行目においてErr.Numberプロパティが0でなくなるから29行目が実行され，beforeCustomerID変数には-1が格納されることになる。そして，44行目では，IDフィールドの値が-1であるレコードを探そうとするわけだが，IDフィールドの値は必ず正であるように顧客情報テーブルを設計したため，そのようなレコードは存在せず，Findメソッドによる検索は失敗することになる。
しかし，削除対象となるレコードが消え，かつ，その次となるレコードが存在しないというケースは，一番最後のレコードが削除されるという場合のみである。Findメソッドによる検索が失敗したときには，カレント行はレコードの末尾のさらに後ろ（EOF）に移動するから，このような処理で事実上問題となることはない。
Fig.7-35 削除の問い合わせ
 |
Chapter 7 27/65 |  |
