メインコンテンツまでスキップ
バージョン: 20 R7 BETA

INTEGRATE MIRROR LOG FILE

INTEGRATE MIRROR LOG FILE ( pathName ; operationNum {; mode {; errObject}} )

引数型説明
pathNameText→統合されるログファイルの名前もしくはパス名
operationNumReal→統合が開始されるオペレーションの番号
←最後に統合されたオペレーションの番号
modeInteger→0=厳格な統合モード(デフォルトモード)、1=自動修復モード
errObjectObject←失われたオペレーション

説明​

**注意事項:**このコマンドは4D Serverでのみ作動します。Execute on serverコマンド経由あるいはストアドプロシージャー内でのみ実行可能です。

INTEGRATE MIRROR LOG FILE コマンドは、pathName で指定したログファイルの、引数operationNum番より後のオペレーションを、4D Server データベースへと統合します。 このコマンドはどんなログファイルをもデータベースに統合することができます(たとえログファイルがカレントのデータファイルと対応していなくても 受け入れます)。このコマンドは特にミラーデータベースのコンテキストで使用することを目的としています。

注: 4D v14 以降、ログファイルを"ミラー"データベースの一部として使用することができます。"ログファイルを使用"のオプションは、論理ミラーとして使用されてい る4D Server のデータベース設定においてチェックが出来るようになりました。これにより、ミラーのミラーサーバーを実装することが出来るようになりました(4D Serverマニュアルの論理ミラーの設定の章を参照して下さい)。

既存の*_o_INTEGRATE LOG FILE* コマンドとは異なり、INTEGRATE MIRROR LOG FILE コマンドは実行を終了したあとにカレントログファイルを統合されたログファイルで置き換えることはしません。データベースのカレントログファイルは引き続き使用されます。これにより、統合の最中に変更されたものは全てカレントのログファイルへと記録されます。

pathName 引数には、データベースフォルダへの絶対パスまたは相対パスを渡します。この引数に空の文字列を渡した場合、標準のファイルを開くダイアログボックスが開 くので、そこから統合したいファイルを選択することができます。このダイアログボックスがキャンセルされると、どのファイルも統合されることなく、 OK システム変数は0に設定されます。

operationNum変数には、最後に統合されたオペレーションの番号を渡します。これによりこの次の番号のオペレーションから統合が開始されます。統合後、operationNum変数は最後に統合されたオペレーションの番号で更新されます。この変数は必ず保存し、次回統合オペレーション時に直接operationNum引数として使用して下さい。これによりINTEGRATE MIRROR LOG FILEコマンドを使用して引き続き連続したログファイル統合をすることができます。ログファイルのオペレーションを全て統合するには、変数に-2を渡して下さい。

*互換性に関する注意: v15 R4以前の4Dでは、 operationNum引数は任意の引数でした。しかしながら、今後は operationNum引数が省略されていた場合、エラーが生成されるようになりました。以前のコードの元の機能を復元するためには、 operationNum引数変数に-2を渡して下さい。

mode引数には、起動したい統合モードを渡します。"Backup and Restore"テーマ内にある、以下の定数から一つ使用する事ができます:

定数型値コメント
Auto repair mode倍長整数1自動修復アクションでフレキシブルモードを使用し、結果をerrObject 引数に返す(あれば)
Strict mode倍長整数0厳格な統合モードを使用する(デフォルト)
  • Strict mode: このモードでは、統合中にエラーが発生した場合統合を中止し、その後エラーを追跡するにはMSCを使用する必要があります。この安全なモードはデフォルトで使用されており、ほとんどの場合において推奨されます。
  • Auto repair mode: このモードでは、致命的でないエラーが発生した場合にはそのエラーはバイパスされ統合は続行されます。errObject引数を渡していた場合、各エラーは記録され、後から解析する事ができます。
    致命的でないエラーに該当するのは以下のエラーです:
    • ログがレコードの追加をリクエストしたが、そのレコードは既にデータ内に存在していた場合。
      修復アクション: 4Dはレコードを更新します。
    • ログがレコードの更新をリクエストしたが、そのレコードはまだ存在していなかった場合。
      修復アクション: 4Dはレコードを追加します。
    • ログがレコードの削除をリクエストしたが、そのレコードは存在していなかった場合。
      修復アクション: 4Dは何もしません。

注: 厳格なStrictモード(デフォルトのモード)では、統合は最初に発生したエラーで中止されます。この場合、統合を続行したい場合にはMSCを使用する必要があります。

自動修復モードで上記のいずれかのエラーが発生した場合、関連するレコードは自動的に"修復"され、関連したオペレーションはerrObject引数に記録されます。実行が完了した後、errObject引数は修復したレコードを全て格納します。ここには以下のようにビルドされた、"operations"という名前の単一のオブジェクト配列が含まれます:

{"operations":    [        {            "operationType":24,            "operationName":"Create record",            "operationNumber":2,            "contextID":48,            "timeStamp":"2015-07-10T07:53:02.413Z",            "dataLen":24,            "recordNumber":0,            "tableID":"F4CXXXXX",            "tableName":"Customers",            "fields": {                "1": 9,                "2": "test value",                "3": "2003-03-03T00:00:00.000Z",                "4": "BlobPath: Table 1/Field 4/Data_9ACB28F1A2744FDFA5822B22F18B2E12.png",                "8": "BlobID: 2"              }        },        {...}     ]

警告: 自動修復モードは4D内部の統合チェック機能をバイパスするため、特定の場合においてのみ使用されるべきモードです。例えば、中間ログファイルが紛失あるいは破損しているために可能な限り多くのオペレーションを復元したい場合などに使用できます。どのような状況においても、このモードを使用する場合にはデータ統合に特別な注意を払う必要があります。

実際に表示されるプロパティの一覧は、オペレーションのタイプによります(例:レコード作成、レコード削除、レコード編集、Blobg作成、等)。主なプロパティは以下の通りです:

  • operationType: オペレーションの内部コード
  • operationName: オペレーションの種類、例えば"create record"や"modify record"など
  • operationNumber: ログファイル内でのオペレーションの内部番号
  • contextID: 実行コンテキストのID。コンテキストの詳細はextraDataのセクションで説明されています。
  • timeStamp: ログファイル内のオペレーションのタイムスタンプ
  • dataLen: データの内部サイズ
  • recordNumber: 内部でのレコード番号
  • tableID: テーブルの内部ID
  • tableName: テーブル名
  • fields: フィールドの一覧を含むオブジェクトとその値。テーブル内の全てのフィールドは記録されています。
    Blobまたはピクチャーの値の場合、その保存場所に応じて異なる種類の情報が提供されます:
    • Blobまたはピクチャーがデータファイルの中に保存されていた場合、このプロパティは"BlobID:"+内部Blob番号 になります。例: "BlobID:1"
    • Blobまたはピクチャーがデータファイルの外に保存されていた場合、このプロパティは"BlobPath:" + データのパス になります。 例: "BlobPath: Table 1/Field 6/Data_EE12D091535F9748BCE62EDE972A4BA2.jpg"
  • extraData: ユーザーコンテキストデータ。ここにはユーザー名とID、タスク名とID、ホストマシン名、クライアントのバージョンが含まれます。
  • sequenceNumber: 自動インクリメントシークエンスのカレントの番号
  • primaryKey: 主キーの値

例題​

ミラーサーバー上のログファイルを自動修復モードで統合したい場合を考えます:

  //サーバー上で実行すること
 var $err : Object
 var $num : Integer //-2 を渡すと全てのオペレーションを統合します。
 INTEGRATE MIRROR LOG FILE("c:\\mirror\\logNew.journal";$num;Auto repair mode;$err)

システム変数およびセット​

統合が正しく実行されるとシステム変数OKに1が、そうでなければ0が設定されます。

参照​

LOG FILE TO JSON

プロパティ​

コマンド番号1312
スレッドセーフである✓
システム変数を更新するOK、error