プログラムの作成に対するアプローチ

1. 最終の画面のイメージを設計するのは良いが、開発中にはあまり画面にこらない、むしろ全体の構成をしっかり設計する。

2. 必ず入力された値のチェックが必要になる、 可能性をリストアウトする。 エラーを先に想定すること。

3. 検索する部分、やループで回るところは、充分考えて、いかに最適化するかを考える。 ループの中で値を関数でとるときループの外に持ち出せないかを考える。 いくつかのアプローチで作りそれぞれを比較する。

4. どんなにきれいにプログラムを書いてもデータベースの構造を間違えると、非常に効率の悪いものになる。 複数のデータベースを扱うとき、リレーションをきるべきか、参照にとどめるのかを考える。

5. REINDEXを使わなければいけないような書き方はしない。 更新されるときは、必要ならインデックスはオープンされているべきです。

6. 固定的な値をデータベースに入れないで、変数としてプログラムの先頭で定義できないか考える。

7. 変数は見やすく、ローカルに使うのか、グローバルに使うのかをしっかり考える。 同じ名前の変数を違ったとサブプログラムで違う用途に使わない。

8. 動作が期待したのと違う、デバッガーを起動してみてみてください。 変数をWatchウィンドウに指定するとどのように変化するかわかります。 古典的な Waitで表示するのも一つの方法ですが、まずは新しいものになれてから判断してください。

9. パネルペインターでどんなコードが吐き出されるか、見てみてください。 実際に動かし、デバッガーで見ると動作がよく分かると思います。

データ更新のヒストリーの一案

CCustomerID ..いろいろなデータ... 更新日付 更新者......

のデータを扱っているとき。

変更されているデータとそれ以外のすべてのデータをテンポラリー書く、

確認処理後、マスターを書き換えて更新する、テンポラリーには最終作業者名、最終更新日が残る、同じ内容はマスターにもある、 次の更新のときはマスターは書きかえられるが、テンポラリーはAPPENDされていく、これがヒストリーになる。 ヒストリーとして参照するときはこのヒストリー件テンポラリのデータベースから同じCustomerIDを検索しリストアウトすると、完全な更新記録が出る。

但し、最初の骨格のプログラムを作るときは、この部分はコメントとして、全体ができてから、このような部分を作成する。

いくつかの考え方

seek()していくつかの一致するレコードを扱う。

If seek(seename)

do while seekname $ fieldname

? name

skip

enddo

endif

検索するseeknameが見つかったら、検索している（インデックスのかっかている）フィールドfieldnameにその文字列があったならdo whileを回る。

LOOKUP( )をご存知ですか？

例えばdbfに次のようなフィールド項目があるとします。

商品コード、 商品名、価格

Lookingfor=検索する商品コード

ANSWER＝ LOOKUP( 商品名、Lookingfor、商品コード)

このＡＮＳＷＥＲには見つかると、商品名を返します。

見つからないとそのフィールドの型のnull値を返します。

ですから商品名は文字型だとすると、" "になります。 このLOOKUP( )はインデックスがあるとインデックス検索をします。 ないとLocateと同じです。 Locateでも数千くらいでしたら、まったく変わらないと思います。

いろいろとARAGOにはコマンドや関数があります。 暇なときにときどき目を通すと良いでしょう。

またコードがどうも汚くなりすぎたと思ったときに、同じことを別の表現でできないかを見てみましょう！

遅いプログラムは、そのプログラム自体の問題化、マシンの設定がおかしいときに起こります。

最近のWindowsはサービスパックなどをインストールするたびに肥大化しています。 ノートパソコンでWindows 95を8メガバイトのメモリーで動かしていて、ARAGOのアプリケーションが動かないなんていわないでください。 昔はWindows 95は8メガバイトのメモリーでも動いていたでしょうが、もう無理です。 Windows NTでも 16メガバイトが最低です。 ノートの場合はメモリーがずいぶん高くつきます。ましてや古い機種ですと、メモリーの価格を考えると新しくノートを買い換えたほうが安い場合があります。

フォアグラみたいに、やたらに詰め込んで、もう動かないなんていわないでください。