<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Moin Herr Allers, Moin Herr Berger,<br>
    <br>
    vielen Dank für die schnellen Antworten.<br>
    <br>
    Im Augenblick sehe ich (auch dank eines Gesprächs mit Herrn Lehmann)
    klarer. Momentanes vorgehen:<br>
    <br>
    - aktuelle Version besorgen<br>
    - Allegro entweder auf den einzelnen Arbeitsrechnern oder auf einem
    Server "installieren"<br>
    - Datenbank zentral auf einem Server (im Intranet) lagern<br>
    <br>
    Nun besteht noch das Problem dass ein Arbeitsrechner in einem
    anderen Gebäude steht. Also eine direkte Verbindung über das
    Intranet nicht möglich ist. Hinzu kommt, dass dieser Rechner (noch)
    über keine Internetverbindung verfügt. Verstehe ich dass richtig,
    dass es keine "einfache" und sichere Möglichkeit gibt, die Daten
    dieses Rechners mit den Daten des Servers (in dem eigentlichen
    Intranet) zu synchronisieren? Oder gibt es zumindest einen Weg, den
    Datenbestand des Arbeitsrechners ohne Internetanschluss in den
    Datenbestand des Servers (im eigentlichen Intranet) Einzupflegen?
    Meine Idee hierzu wäre z.B. Auf dem Arbeitsrechner ohne
    Internetanschluss eine Exportdatei (xyz.adt) zu erstellen, und diese
    über einen Arbeitsrechner im Intranet in den Datenbestand auf dem
    Server zu überführen.<br>
    <br>
    Schönen Gruß,<br>
    <br>
    Moritz Tietjens.<br>
    <br>
    <div class="moz-cite-prefix">Am 05.02.2013 09:12, schrieb Thomas
      Berger:<br>
    </div>
    <blockquote cite="mid:5110BEEB.9060207@Gymel.com" type="cite">
      <pre wrap="">Lieber Herr Tietjens, lieber Herr Allers,

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">Dann dachte ich mir, beim Start von Allegro-C die Daten vom Server auf 
den Arbeitsrechner zu speichern, die log-Datei zu löschen, mit dem 
Datenbestand auf dem Client zu arbeiten, die log-Datei in eine .alg 
umzuwandeln (LOG2ALG.EXE) und damit und dem Programm UPDATE.EXE die 
Datenbank auf dem Server über das Netzlaufwerk zu synchronisieren.  Das 
geht aber auch nicht, k.a. warum.
</pre>
        </blockquote>
        <pre wrap="">
So wurde es gemacht, als es noch keine Netze gab oder bevor Allegro netzfähig war, aber heute ich diese 
Technik mehr als überholt.
</pre>
      </blockquote>
      <pre wrap="">
Ich war vor Jahren in einem solchen Fall damit befasst, die
Scherben aufzukehren:

Solche lokalen Kopien von Datenbanken haben eine gewisse Anzahl
von Datensaetzen die gewisse Identnummern tragen. Wird damit
unabhaengig voneinander (schreibend) weiter gearbeitet,
entstehen neue Datensaetze mit jeweils einer internen Satznummer
und einem Primaerschluessel in der dafuer eingerichteten Kategorie
(etwa #00 bei A.CFG). Beide entstehen i.W. durch "Hochzaehlen"
von etwas vorhandenem.

Wird also in zwei Datenbanken unabhaengig voneinander gearbeitet,
entstehen zwangslaeufig Datensaetze mit gleichen Satznummern
und Primaerschluesseln, normalerweise aber durchaus verschiedener
Bedeutung. Kein Updateprozess (der Logdatei im "Playback"-Modus
die internen Satznummern nutzend bzw. der in .ALG umgewandelten
Logdatei, die Primaerschluessel nutzend) wird Ihnen diese
verschiedenen Bedeutungen auseinander halten. Die Bemerkungen
zu "Replikation" im Handbuch und sonstwo sind stets im Sinne
einer "Master-Slave"-Replikation zu verstehen, d.h. zwischen
zwei Synchronisationen wird unbedingt und stets in maximal eine
der Datenbankkopien geschrieben.

Das von Ihnen Beschriebene funktioniert, wenn man (etwa durch
individuelle Prae- oder Suffixe an der Identnummer) Vorkehrungen
trifft, dass jede dieser Datenbankkopien garantiert Identnummern
erzeugt, die verschieden von denen jeder anderen Kopie sind.
Dann kann man ein Update-Verfahren anhand der umgewandelten
Logdatei oder sogar anhand eines einfachen Exports der seit einem
Stichzeitpunkt geaenderten Datensaetze tatsaechlich eine saubere
Replikation hinbekommen, allerdings muss auch hier durch
redaktionelle Vorgaben (wer darf wann Saetze mit "fremden"
Identnummern anfassen) die Anzahl der Bearbeitungskonflikte
minimiert werden, da die hoechstens automatisch erkannt, aber
nicht automatisiert geloest werden koennen.

viele Gruesse
Thomas Berger

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Allegro mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Allegro@biblio.tu-bs.de">Allegro@biblio.tu-bs.de</a>
<a class="moz-txt-link-freetext" href="http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro">http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">-----
E-Mail ist virenfrei.
Von AVG überprüft - <a class="moz-txt-link-abbreviated" href="http://www.avg.de">www.avg.de</a>
Version: 2013.0.2890 / Virendatenbank: 2639/6056 - Ausgabedatum: 25.01.2013 
Die Virendatenbank sind veraltet.
</pre>
    </blockquote>
    <br>
  </body>
</html>