Vorbemerkung: Dieser Befehl arbeitet nur mit 4D Server. Er lässt sich nur über die Funktion Execute on server oder in einer Serverprozedur ausführen.

Der Befehl INTEGRATE MIRROR LOG FILE integriert das Journal, das im Parameter PfadName angegeben ist, in eine 4D Server Datenbank, optional nach der Operation, angegeben in OperationNr. Dieser Befehl erlaubt, jedes Journal in die Datenbank zu integrieren, auch wenn es nicht dem aktuellen Status der Datendatei entspricht. Er eignet sich speziell zur Verwendung im Kontext einer Spiegeldatenbank. 

Hinweis: Ab 4D v14 lässt sich ein Journal als Teil einer Spiegeldatenbank verwenden. Die Option "Benutze Logbuch" lässt sich auch in den Datenbank-Eigenschaften eines 4D Server markieren, der als Spiegel-Server verwendet wird. Auf diese Weise ist das Implementieren einer Reihe verschachtelter Spiegel-Server möglich. Weitere Informationen dazu finden Sie im Abschnitt Logischen Spiegel einrichten des Handbuchs 4D Server.

Dieser Befehl ersetzt, im Gegensatz zum Befehl _o_INTEGRATE LOG FILE am Ende der Ausführung nicht das aktuelle Journal durch das integrierte: Das aktuelle Journal der Datenbank wird weiter verwendet. So werden alle Änderungen während der Integration im aktuellen Journal gesichert.

In PfadName übergeben Sie einen absoluten oder relativen Pfad des Datenbankordners. Übergeben Sie einen leeren String, erscheint ein Standard-Öffnen Dialog, so dass Sie die Datei zum Integrieren wählen können. Wird dieser Dialog abgebrochen, wird keine Datei integriert und die Systemvariable OK auf 0 gesetzt.

Standardmäßig, d.h. ohne den Parameter OperationNr, integriert der Befehl alle Operationen des Journals.
Übergeben Sie einen Wert in OperationNr, beginnt die Integration mit der Operation mit der nächsthöheren Nummer. Nach der Integration wird der Wert der Variablen OperationNr mit der Nummer der zuletzt integrierten Operation aktualisiert. Sie müssen diese Variable sichern und können sie dann als Parameter OperationNr für die nächste Operation zum Integrieren verwenden. So können Sie mit INTEGRATE MIRROR LOG FILE nachfolgende Logbücher direkt im Anschluss integrieren.

Hinweis zur Kompatibilität: Bisher war der Parameter OperationNr optional; ab v15 R4 ist er zwingend, d.h. wird OperationNr weggelassen, wird ein Fehler generiert. Wollen Sie die bisherige Funktionsweise wiederherstellen, übergeben Sie -2 als Variablenwert des Parameters.

In Modus übergeben Sie den gewünschten Integrationsmodus. Sie können zwischen zwei Konstanten unter dem Thema "Backup und Wiederherstellen" wählen:

• Strikter Modus: Wie in bisherigen 4D Versionen stoppt die Integration, wenn ein Fehler auftritt und Sie müssen das MSC aufrufen, um den Fehler nachzuverfolgen. Dieser Modus wird standardmäßig verwendet und bietet sich in den meisten Fällen an.

• Auto repair Modus: Treten in diesem Modus nicht-kritische Fehler auf, werden sie übersprungen und die Integration läuft weiter. Ist der Parameter errObjekt übergeben, wird der Fehler protokolliert und kann später analysiert werden.
  Fälle für nicht-kritische Fehler sind:
  
  • Das Journal meldet, einen Datensatz hinzuzufügen, aber dieser Datensatz ist bereits in den Daten vorhanden.
    Aktion zum Reparieren: 4D aktualisiert den Datensatz 
  • Das Journal meldet, einen Datensatz zu aktualisieren, aber dieser Datensatz existiert noch nicht.
    Aktion zum Reparieren: 4D fügt den Datensatz hinzu.
  • Das Journal meldet, einen Datensatz zu löschen, aber dieser Datensatz existiert nicht.
    Aktion zum Reparieren: 4D führt nichts aus.

Tritt eine dieser Unregelmäßigkeiten im auto-repair Modus auf, wird der betroffene Datensatz automatisch "repariert" und die entsprechende Operation wird im Parameter errObjekt protokolliert. Nach abgeschlossener Ausführung listet der Parameter errObjekt alle reparierten Datensätze. Er enthält ein Array Objekt mit Namen "operations" in folgender Form:

Warnung: Der auto-repair Modus darf nur in spezifischen Fällen verwendet werden, da er die 4D Kontrollfunktionen zur internen Datenintegration übergeht. Ein solcher Fall wäre z.B., wenn ein dazwischen liegendes Logbuch verloren ging oder beschädigt ist, und Sie möglichst viele Operationen wiederherstellen wollen. In diesem Modus müssen Sie besonders auf die Datenintegrität achten.

Die aktuelle Liste der verfügbaren Eigenschaften richtet sich nach der Art der Operation (z.B. Datensatz erstellen, Datensatz löschen, Datensatz ändern, Blob erstellen). Hier die Haupteigenschaften:

• operationType: interner Code der Operation
• operationName: Art der Operation, z.B. "Datensatz erstellen," "Datensatz ändern"
• operationNumber: interne Nummer der Operation im Logbuch
• contextID: ID des Ausführungskontexts
• timeStamp: Zeitstempel der Operation im Logbuch
• dataLen: interne Größe der Daten
• recordNumber: interne Datensatznummer
• tableID: interne ID der Tabelle
• tableName: Name der Tabelle
• fields: Objekt mit der Liste der Feldnummern (oder Feldnamen) mit ihren Werten. Jedes Feld mit einem geänderten Wert wird protokolliert.
  Bei Werten vom Typ Blob oder Bild wird je nach Speicherort unterschiedliche Information geliefert:
  
  • Beim Speichern innerhalb der Datendatei lautet die Eigenschaft "BlobID:"+ eine interne Blob Nummer, z.B.: "BlobID:1"
  • Beim Speichern außerhalb der Datendatei lautet die Eigenschaft "BlobPfad:" + Datenpfad, z.B.: "BlobPath: Table 1/Field 6/Data_EE12D091535F9748BCE62EDE972A4BA2.jpg"
• extraData: Daten des Benutzerkontexts mit Benutzername und ID, Task-Name und ID, Name des Host Rechners und Client Version
• sequenceNumber: Aktuelle Nummer in der automatisch durchnummerierten Sequenz
• primaryKey: Wert des Primärschlüssels

Ein Spiegel Logbuch auf dem Server im auto-repair Modus integrieren:

Bei korrekt ausgeführter Integration wird die Systemvariable OK auf 1 gesetzt; andernfalls auf 0 (Null).