
    ZENTRAL/FILIAL DATENBANK


    Um Auf eine Zentral/Filialdatenbank umzustellen sind folgende Schritte notwendig:

    Die Datenbank muss in der Filiale den selben Namen wie in der Zentrale haben, da der Datenbankname mitgeschrieben
    wird.

    WICHTIG !!! Es kann nur eine Zentrale Geben!!

    ZENTRALE

    In der Zentrale ist in der Konfiguration der Parameter $config['db_work_as'] auf 0 (NULL) zu stellen.
    Weiters muss der Parameter $config['protolog'] auf 1 gestellt werden. Alle Aktionen in der Datenbank werden nun
    mitgeschrieben (Datenanlage, Änderungen etc).

    Der Parameter $config['protolog_conf'] sollte in der Zentrale auf 0 stehen. Der Parameter bewirkt, dass Änderungen
    an der Konfiguration NICHT mitgeloggt werden. Steht der Parameter auf 1, werden auch Änderungen der Zentrale an der
    Konfiguration mit ins Logfile geschrieben. Das führt schnell zu unerwünschten Effekten.

    FILIALE

    In der Filiale muss der Parameter $config['db_work_as'] auf 1 gestellt werden. Das hat zur Folge, dass die Filiale
    sowohl keine neuen Daten anlegen, als auch bestehende nicht editieren kann (Beide Buttons fehlen).
    Daten werden ausnahmslos NUR in der Zentrale angelegt oder verändert. Alle anderen Funktionen bleiben erhalten.

    IN ZENTRALE UND FILIALE

    Daten triggern und zum Versenden bereitstellen, bzw in der Filiale einlesen:

    Entweder man ruft über die Administration -> Auswertungen und Tools -> Filialfile erstellen die Abarbeitung der Daten
    händisch auf oder lässt die Datei crontabtrigger.php als Cronjob laufen (Ein Shellscript namens trigger_adressql liegt
    unter bash/).
    Es sollte niemand in der Datenbank arbeiten, wenn dieser Punkt ausgeführt wird. Am Besten man lässt Nachts das
    Script per CRON laufen.
    Im Shellscript muss noch der Pfad angepasst werden, sonst klappt das Script nicht!!

    Das Script stellt fest, ob man Filiale oder Zentrale ist und exportiert oder Importiert entsprechend die Daten.
    Das Script sucht nach der Datei templates/admin/triggerdata/.httrigimport. Wird die Datei gefunden, werden
    alle Daten dieses Files abgearbeitet, in der Zentrale werden alle angefallenen Daten exportiert und in diese Datei geschrie-
    ben, in der Filiale wird das File automatisch gelöscht, um ein doppeltes Einlesen zu verhindern.

    ACHTUNG !!
    Grosse Datenmengen verursachen lange Laufzeiten und/oder grosse Files. PHP ist aber was die Laufzeiten angeht von den
    Einstellungen der php.ini abhängig.
    Entweder man stellt die php.ini so ein, dass es keine Laufzeitfehler gibt und PHP eventuell abbricht oder man sorgt dafür,
    dass die Datenmengen entsprechend klein gehalten werden.

    Da die PHP-cli (Aufruf eines Scripts über die shell) über eine eigene php.ini verfügt, könnten hier die Laufzeiten ent-
    sprechend angepasst werden.

    Wer mit sehr sehr grossen Datenmengen hantiert (mehrere tausend Daten je Tag), sollte die Problematik aber anders lösen.

    Zwischen Zentrale und Filiale muss nun noch der Austausch der Datei geregelt werden. Je nach technischen Möglichkweiten
    bieten sich mehrere Varianten an. Ich selbst mounte das Export-Verzeichnis per nfs in die Filiale und starte einen Kopier-
    prozess. Eine Übertragung per FTP wäre aber ebenfalls denkbar, der Phantasie sind keine Grenzen gesetzt.

    FEHLERSUCHE !!

    a.)
    Die Daten werden in der Filiale nicht geschrieben.

       WICHTIG !!
       ALLE Datenbanken MÜSSEN gleich heissen (den selben Datenbanknamen und die selben Tabellennamen und Spaltenbezeichnungen
       verwenden), da beim Erstellen der Log (TRIGGER) Einträge der Datenbankname und Feldname der Tabellen mitgeloggt wird.
       Unterschiedliche Namen führen entweder zu einem Fehler oder die Daten werden in die falsche Datenbank übernommen.
       Bei der Installation sollte also das selbe install.php Script mit den selben Einstellungen laufen.

            !!!! EINZIG Die Zugangsdaten (Username und Passwort) zur Datenbank können abweichen !!!!

       1. Werden in der Filiale SQL-Anweisungen NICHT mitgeloggt steht wahrscheinlich $config['protolog'] = 0
       2. Ist die Filiale auch als solche eingetragen ($config['db_work_as'] = 1)?

    b.)
    Eigene SQL-Anweisungen werden nicht an die Filiale geschickt.

        Eigene Scripte können zu Fehlern im logging führen.
        Wer eigene SQL-Statements ins Script eingefügt hat, sollte den Befehl dbquery($sql) verwenden um die SQL-Befehle an
        die Datenbank zu schicken, da dort (in der Funktion) das Logging und der Eintrag in die protokoll-Tabelle erfolgt.
        Alle SQL-Anweisungen werden dort nach bestimmten Kriterien durchsucht und gegebenenfalls geloggt.
        Die Kriterien stehen in der datei /vars/.htprotokoll. Eventuell werden SQL-Befehle verwendet, die dort nicht einge-
        tragen sind. Fügen sie Ihre Kriterien hinzu. Der Logger verwendet stristr() als Vergleichsfuktion, eine Kontrolle der
        Gross/Kleinschreibung ist also nicht notwendig.

    c.)
    Es wird kein Filialfile erstellt.

        Das Filialfile beginnt mit .ht als Präfix, Linux blendet diese Dateien aus. Eventuell muss im Dateimanager die Anzeige
        solcher Dateien eingeschalten werden.

        Sind die Rechte auf schreiben für das Verzeichnis /templates/admin/triggerdata gesetzt?

    d.)
    Die Filiale stellt sich immer wieder auf Zentrale um.

        Der Parameter $config['protolog_conf'] sollte in der Zentrale auf 0 stehen, steht aber auf ungleich 0.
        Alle Änderungen an der Konfiguration in der Zentrale werden mitgeloggt. Stellt man dort also z.B.
        Die Mailadresse um, wird das auch der Filiale geschickt.
        Es werden aber immer alle Parameter der Konfiguration in die Datenbank geschrieben, also auch ob man Zentrale oder
        Filiale ist. Die Filiale bekommt also den Parameter db_work_as mit null als Transfer übermittelt.

        Stellen Sie den Parameter $config['protolog_conf'] in der Zentrale auf 0 (NULL).

    e.)
    Es werden keine Uploads in die Filale kopiert

        Das ist auch so gewollt. Der Trigger nimmt nur Datenbank Aktionen mit, File-Aktionen werden nicht getriggert.
        Ansichten gibt es viele, ich stehe auf dem Standpunkt, dass z.B. Uploads nicht zentral verwaltet werden sollten.



