4D v16.3VERIFY DATA FILE |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4D v16.3
VERIFY DATA FILE
VERIFY DATA FILE
VERIFY DATA FILEコマンドは、structurePathとdataPathで指定したデータファイル中にあるオブジェクトの構造的な検証を行います。 注: データ検証に関する詳細は、Design Referenceマニュアルを参照してください。 structurePathは、 検証するデータファイルに対応するストラクチャーファイル (コンパイル済みまたはインタプリター) を指定します。開かれたストラクチャーや他のストラクチャーを指定できます。OSに対応した完全パス名を指定しなければなりません。空の文字列を渡すと標準のファイルを開くダイアログボックスが表示され、使用するストラクチャーファイルをユーザーが指定できます。 dataPath は4Dデータファイル (.4DD) を指定します。データファイルはstructurePath引数で指定されたストラクチャーファイルに対応していなければなりません。カレントストラクチャーファイルを指定することができますが、カレントのデータファイルは指定できない (開かれていてはいけない) ことに注意してください。現在開かれているデータファイルを検証するためには VERIFY CURRENT DATA FILE コマンドを使用します。VERIFY DATA FILEでカレントのデータファイルを検証しようとすると、エラーが生成されます。 指定されたデータファイルは読み込みのみで開かれます。他のアプリケーションが書き込み可能でこのファイルにアクセスしないようにしなければなりません。そうでなければ検証結果は正しくないものになります。 objects 引数は検証するオブジェクトを指定するために使用します。2つのタイプのオブジェクト、レコードとインデックスを検証できます。Data File Maintenanceテーマの以下の定数を使用できます:
レコードとインデックス両方を検証するにはVerify Records+Verify Indexesを渡します。0を渡しても同じ結果が得られます。Verify Allオプションを指定すると内部的な検証が完全に行われます。この検証はログの作成と互換性があります。 options 引数は検証オプションを設定するために使用します。オプションは Data File Maintenance テーマの中から指定できます:
通常、VERIFY DATA FILE コマンドは XMLフォーマットのログファイルを作成します (このコマンドの最後の説明を参照してください)。このオプションを指定して、ログの作成をキャンセルできます。ログファイルを作成するには、optionsに0を渡します。 method 引数には、検証中定期的に呼び出されるコールバックメソッドを設定するために使用します。空の文字列を渡すと、メソッドは呼び出されません。渡されたメソッドが存在しない場合、検証は行われず、エラーが生成され、OKシステム変数に0が設定されます。コールバックメソッドが呼び出されるときは、検証されるオブジェクトのタイプおよび呼び出し元のイベントタイプにより最大5つの引数が渡されます。コールバックメソッドではこれらの引数を宣言しなければなりません:
以下の表は、イベントタイプごとの引数の内容を示しています:
(**) Object type: オブジェクトタイプ: オブジェクトが検証されると、OKメッセージ ($1=2)、エラー ($1=3)、警告 ($1=5) が送信されます。$2に返されるオブジェクトタイプは以下のうちのいずれかになります:
特別なケース: $1が2、3、または5のとき、$4が0ならば、それはメッセージがテーブルやインデックスについてではなく、データファイル全体に関するものであることを示します。 コールバックメソッドは$0に倍長整数値を返さなくてはなりません。これは処理の実行をチェックするために使用されます:
注: 実行終了イベント ($4=1) が生成された後、$0を使用して実行を中断させることはできません。 2つのオプションの配列をこのコマンドで利用できます:
この引数が渡されないか配列が空の場合で、objects引数にVerify Indexesが指定されている場合、すべてのインデックスが検証されます。コマンドはインデックスの無いフィールドを無視します。フィールドに複数のインデックスが含まれる場合、すべてが検証されます。フィールドが複合インデックスの一部である場合、インデックス全体が検証されます。 デフォルトでVERIFY DATA FILEコマンドは、(options引数にDo not create log fileオプションが指定されていなければ) XMLフォーマットのログファイルを作成します。このファイルはカレントデータベースのLogsフォルダに作成され、名前もカレントデータベースのストラクチャーファイルに基づいたものがつけられます。例えば、“myDB.4db”という名前のストラクチャーファイルに対しては、ログファイルは“myDB_Verify_Log.xml”という名前が付けられます。Timestamp log file nameオプションを渡していた場合、ログファイル名には"YYYY-MM-DD HH-MM-SS"という形式で作成時の日時の情報が含まれます。ファイル名は例として次のような形になります:“myDB_Verify_Log_2015-09-27 15-20-35.xml” これはつまりそれぞれの新しいログファイルは以前のものを置き換える事はない一方、不要なファイルを削除するためにはいくつかのファイルを手動で削除しなければならない可能性があることを意味します。 データとインデックスの検証: VERIFY DATA FILE($StructName;$DataName;Verify indexes+Verify records;Do not create log file;"") 完全な検証を行い、ログを作成する: VERIFY DATA FILE($StructName;$DataName;Verify all;0;"") レコードのみの検証: VERIFY DATA FILE($StructName;$DataName;Verify records;0;"") テーブル3と7のレコードのみを検証: ARRAY LONGINT($arrTableNums;2) 特定のインデックスを検証 ([table4]field1、[table5]field2とfield3): ARRAY LONGINT($arrTableNums;0) `使用しないが必須 コールバックメソッドが存在しない場合、検証は実行されず、エラーが生成され、OKシステム変数には0が設定されます。ログファイルが生成されていた場合、その完全パス名がDocumentシステム変数へと返されます。
参照
|
プロパティ
プロダクト: 4D 履歴
変更: 4D v11 SQL Release 3 ARTICLE USAGE
ランゲージリファレンス ( 4D v16) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||