version 6.0
テーブルやレコードを使用してディスク上に格納したデータと異なり、配列は常に全部がメモリに保持されます。
例えば、米国内の郵便番号がすべて[Zip Codes]テーブルに入力されている場合、約100,000件のレコードになります。加えて、そのテーブルは郵便番号の他に、対応する市、郡、州という複数のフィールドを持つとします。カリフォルニアからのみ郵便番号を選択する場合、4Dデータベースエンジンが[Zip Codes]テーブルの対応するレコードセレクションを作成して、必要な場合にのみそのレコードをロードします(例えば表示や印刷時)。すなわち、4Dのデータベースエンジンによってディスクからメモリに部分的にロードされた(フィールドごとに同じタイプの)順序づけられた一連の値で作業するということです。
同じことを配列で実行するのは、次の理由で禁止されています:
・4つの情報タイプ(郵便番号、市、郡、州)を維持するためには、4つの大きな配列をメモリ内で維持する必要があります。
・配列は、常に全体がメモリ内に維持されるため、あまり使用しない場合でも、作業セッションの間すべての郵便番号をメモリに置いておく必要があります。
・同じく配列全体が常にメモリ内に維持されることから、データが作業セッション中に使用も変更もされていない場合でも、4つの配列をデータベースが開始されるたびディスクからロードして、終了時にはディスクに保存する必要があります。
結論: 配列は、ほどよい量のデータを短時間維持するためのものです。他方、配列はメモリ内に置かれるため、扱いやすく高速操作が可能です。
しかし、状況によっては何百、何千という要素を持った配列で作業する必要があります。
次の表に、各配列がメモリ上に占めるバイト数を求めるための計算式を示します:
| 配列型 | メモリ使用量の計算式 (バイト単位) |
| ブール | (31+要素数)\8 |
| 日付 | (1+要素数) * 6 |
| 文字列 | (1+要素数) * 定義した長さ (奇数バイトなら+1、偶数バイトなら+2) |
| 整数 | (1+要素数) * 2 |
| 倍長整数 | (1+要素数) * 4 |
| ピクチャ | (1+要素数) * 4 + ピクチャサイズの合計 |
| ポインタ | (1+要素数) * 16 |
| 実数 | (1+要素数) * 8 |
| テキスト | (1+要素数) * 6 + テキストサイズの合計 |
| 2次元 | (1+要素数) * 12 + 配列サイズの合計 |
Note: 選択した要素、要素数、配列自体の情報を保持するため、さらに数バイトを要します。
非常に大きな配列で作業する場合、メモリが一杯という状況を扱う最善の方法は、配列の作成をON ERR CALLで囲むことです。以下に例を示します:
` 大きな配列を作成する必要がある晩に一晩かけバッチ操作を実行します。
` 夜間にエラーが発生する危険がないように、操作の始めに配列を作成し、
` この時点でエラーをストします。
gError:=0 ` エラーなし状態にセット
ON ERR CALL ("ERROR HANDLING") ` エラーをキャッチするメソッドをインストール
ARRAY STRING (63;asThisArray;50000) ` 約3125K
ARRAY REAL (arThisAnotherArray;50000) ` 488K
ON ERR CALL ("") ` これ以降は、エラー処理不要
If (gError=0)
` 配列を作ることができた
` そし、操作を続行できる
Else
ALERT ("この操作はメモリ不足により続行ができません!")
End if
` これ以降は、配列は不要となる
CLEAR VARIABLE (asThisArray)
CLEAR VARIABLE (arThisAnotherArray)
ERROR HANDLING プロジェクトメソッドは以下のとおりです:
` ERROR HANDLING プロジェクトメソッド gError:=Error ` エラーコードを返す
参照