<div dir="ltr"><div dir="ltr"><div><br></div><div>Verlautbarung 304 zur allegro-Entwicklung                    2018-12-18</div><div>-----------------------------------------</div><div><br></div><div>update.job</div><div>----------</div><div>Eine Korrektur war nötig, um beim Einspeisen einer .log-Datei</div><div>(Funktion -fp)</div><div>Probleme zu vermeiden. Datei liegt bereit:  X gf update.job</div><div>(Verbesserungen markiert mit $2018-12-18)</div><div><br></div><div>Im ANHANG Mitteilung zum Thema Updating unter Linux.</div><div><br></div><div><br></div><div>Hinweise zur Datensicherung</div><div>---------------------------</div><div><br></div><div>Das Thema wird u.U. nicht überall genügend ernst genommen. Man hat</div><div>schon Fälle erlebt, wo eine Datenbank länger als 10 Jahre gelaufen</div><div>war und immer noch funktionierte, ohne daß je eine Datensicherung</div><div>oder Reorganisation gemacht wurde. So beruhigend man es finden mag,</div><div>daß die Software derart lange problemlos arbeiten kann, wird dennoch</div><div>jeder Administrator Bedenken tragen, ob man's drauf ankommen lassen</div><div>sollte! </div><div>Deshalb hier eine Übersicht der relevanten Hilfssmittel und Dokumente</div><div>zum Thema Datensicherung. </div><div>Die drei wichtigsten Sachen zuerst:</div><div><br></div><div>Eingabe</div><div>in a99: </div><div><br></div><div>h ac-7  : (Handbuch-Kapitel 0.7)</div><div>          Datensicherung: Grundsätzliches zu Konzept und Methoden</div><div>          Darin auch: Kopie der Datenbank mit .log-Datei aktualisieren</div><div><br></div><div>h backp : Menü "Datenbank kopieren", mit Hinweisen für Systemverwalter</div><div>          Menüfunktion zum Anlegen einer Sicherungskopie.</div><div>          Zum regelmäßigen Gebrauch empfohlen!</div><div><br></div><div>h restr : Datenbank restaurieren: Sicherungskopie + .log-Datei</div><div>          Eine Sicherungskopie zurückholen und mit der aktuellen</div><div>          Log-Datei auf den aktuellen Stand bringen</div><div><br></div><div>Einige ergänzende Themen:</div><div>-------------------------</div><div><br></div><div>h super : Ein Supervisor-Menü mit mehreren relevanten Funktionen:</div><div>          u.a. "Log-Datei besichtigen"</div><div><br></div><div>h vb245 : update.job mit neuen Fähigkeiten, u.a. Einspeisen einer .log</div><div><br></div><div>h vb275 : dawa.flx wandelt .log um in .adt (z.B. .bdt, wenn b.cfg)</div><div>          Funktioniert auch mit acon unter Linux.</div><div>          Windows: log2alg.exe wandelt .log um in .alg</div><div>          (die .log selber bleibt in jedem Fall erhalten)</div><div><br></div><div>h archiv: Archiv-Datenbank : Ausgewählte Datensätze archivieren</div><div>          Funktion F8 s : Aktuellen Satz archivieren</div><div><br></div><div><br></div><div>Hält doppelt besser?</div><div>Es ist vorgekommen, daß eine .adt-Datei zweimal eingespeist wurde, wenn</div><div>diese Datei aus einer .log mittels log2alg erstellt wurde.</div><div>Das Problem ist dann: Die neuen Datensätze, deren Kopien sich in der </div><div>Log-Datei befanden, werden dann verdoppelt.</div><div>Wie das kommt? Beim zweiten Einspeisen merkt das Programm nicht, daß</div><div>ein als neu markierter Datensatz in der Datenbank nach dem ersten</div><div>Einspeisen derselben Log-Datei schon vorhanden ist. Das ist schlichtweg</div><div>nicht vorgesehen - denn einmaliges Einspeisen reicht! Wenn das aber</div><div>mal versehentlich passiert ist, was dann? </div><div>Zwei Möglichkeiten:</div><div>a) Im Register der IdNummern die Doppeleinträge finden und dann</div><div>   jeweils einen der beiden identischen Datensätze löschen.</div><div>   So findet man die Doppeleinträge: X ista und dann 9 wählen (h vb301)</div><div>   Wenn es aber sehr viele sind:</div><div>b) Die letzte Sicherungskopie nochmals hervorholen und in diese dann </div><div>   die aktuelle Log-Datei nur einmal einspeisen.</div><div><br></div><div><br></div><div>ANHANG</div><div>------</div><div>Zum Updating unter Linux</div><div>------------------------</div><div>In Bezug auf Linux war am 10.12. eine wichtige Mitteilung an das</div><div>Forum gegangen, die hier wiederholt wird:</div><div><br></div><div>Es gab bei einem 64bit-Linux-Anwender ein Problem: das Hilfsprogramm </div><div>log2alg war nicht lauffähig. (Es wandelt  cat.log um in cat.alg)</div><div><br></div><div>Statt dessen kann man so vorgehen:</div><div><br></div><div>1. Die Logdatei, z.B. cat.log, mit dawa.flx in cat.adt verwandeln</div><div>2. Mit update.job die cat.adt einmischen (Funktion -fm11)</div><div><br></div><div>Denn der dawa.flx ist so gestaltet, daß man ihn auch mit acon benutzen </div><div>kann und auch unter Linux. (Das wurde schon in Vb275 erwähnt.)</div><div><br></div><div>Nehmen wir mal an, in /var/allegro liegen acon und dawa.flx, in </div><div>/var/data/katalog liegt die Datenbank xyz mit m.cfg, d.h. dort liegt </div><div>auch eine xyz.log</div><div><br></div><div>Dann startet man in /var/allegro so:</div><div><br></div><div>./acon -jdawa.flx -d/var/data/katalog -bxyz -km /var/data/katalog/xyz.log</div><div><br></div><div>  anstatt   log2alg /var/data/katalog/xyz.log</div><div>   (dabei käme aber xyz.adt raus, das müßte man umbenennen in xyz.mdt!)</div><div><br></div><div>und kurz darauf kommt die Erfolgsmeldung:</div><div>   Das war's, Datei /var/data/katalog/xyz.mdt ist fertig</div><div><br></div><div>Diese Datei xyz.mdt läßt sich in eine andere m-Datenbank oder eine </div><div>Sicherungskopie ganz normal mit  update.job  und -uPFAD/xyz.mdt -fm11</div><div>einmischen.</div><div><br></div></div></div>