[Allegro] Vb.304: update.job verbessert / Hinweise zur Datensicherung und .log-Datei

[aresqa allegro]

Verlautbarung 304 zur allegro-Entwicklung                    2018-12-18
-----------------------------------------

update.job
----------
Eine Korrektur war nötig, um beim Einspeisen einer .log-Datei
(Funktion -fp)
Probleme zu vermeiden. Datei liegt bereit:  X gf update.job
(Verbesserungen markiert mit $2018-12-18)

Im ANHANG Mitteilung zum Thema Updating unter Linux.


Hinweise zur Datensicherung
---------------------------

Das Thema wird u.U. nicht überall genügend ernst genommen. Man hat
schon Fälle erlebt, wo eine Datenbank länger als 10 Jahre gelaufen
war und immer noch funktionierte, ohne daß je eine Datensicherung
oder Reorganisation gemacht wurde. So beruhigend man es finden mag,
daß die Software derart lange problemlos arbeiten kann, wird dennoch
jeder Administrator Bedenken tragen, ob man's drauf ankommen lassen
sollte!
Deshalb hier eine Übersicht der relevanten Hilfssmittel und Dokumente
zum Thema Datensicherung.
Die drei wichtigsten Sachen zuerst:

Eingabe
in a99:

h ac-7  : (Handbuch-Kapitel 0.7)
          Datensicherung: Grundsätzliches zu Konzept und Methoden
          Darin auch: Kopie der Datenbank mit .log-Datei aktualisieren

h backp : Menü "Datenbank kopieren", mit Hinweisen für Systemverwalter
          Menüfunktion zum Anlegen einer Sicherungskopie.
          Zum regelmäßigen Gebrauch empfohlen!

h restr : Datenbank restaurieren: Sicherungskopie + .log-Datei
          Eine Sicherungskopie zurückholen und mit der aktuellen
          Log-Datei auf den aktuellen Stand bringen

Einige ergänzende Themen:
-------------------------

h super : Ein Supervisor-Menü mit mehreren relevanten Funktionen:
          u.a. "Log-Datei besichtigen"

h vb245 : update.job mit neuen Fähigkeiten, u.a. Einspeisen einer .log

h vb275 : dawa.flx wandelt .log um in .adt (z.B. .bdt, wenn b.cfg)
          Funktioniert auch mit acon unter Linux.
          Windows: log2alg.exe wandelt .log um in .alg
          (die .log selber bleibt in jedem Fall erhalten)

h archiv: Archiv-Datenbank : Ausgewählte Datensätze archivieren
          Funktion F8 s : Aktuellen Satz archivieren


Hält doppelt besser?
Es ist vorgekommen, daß eine .adt-Datei zweimal eingespeist wurde, wenn
diese Datei aus einer .log mittels log2alg erstellt wurde.
Das Problem ist dann: Die neuen Datensätze, deren Kopien sich in der
Log-Datei befanden, werden dann verdoppelt.
Wie das kommt? Beim zweiten Einspeisen merkt das Programm nicht, daß
ein als neu markierter Datensatz in der Datenbank nach dem ersten
Einspeisen derselben Log-Datei schon vorhanden ist. Das ist schlichtweg
nicht vorgesehen - denn einmaliges Einspeisen reicht! Wenn das aber
mal versehentlich passiert ist, was dann?
Zwei Möglichkeiten:
a) Im Register der IdNummern die Doppeleinträge finden und dann
   jeweils einen der beiden identischen Datensätze löschen.
   So findet man die Doppeleinträge: X ista und dann 9 wählen (h vb301)
   Wenn es aber sehr viele sind:
b) Die letzte Sicherungskopie nochmals hervorholen und in diese dann
   die aktuelle Log-Datei nur einmal einspeisen.


ANHANG
------
Zum Updating unter Linux
------------------------
In Bezug auf Linux war am 10.12. eine wichtige Mitteilung an das
Forum gegangen, die hier wiederholt wird:

Es gab bei einem 64bit-Linux-Anwender ein Problem: das Hilfsprogramm
log2alg war nicht lauffähig. (Es wandelt  cat.log um in cat.alg)

Statt dessen kann man so vorgehen:

1. Die Logdatei, z.B. cat.log, mit dawa.flx in cat.adt verwandeln
2. Mit update.job die cat.adt einmischen (Funktion -fm11)

Denn der dawa.flx ist so gestaltet, daß man ihn auch mit acon benutzen
kann und auch unter Linux. (Das wurde schon in Vb275 erwähnt.)

Nehmen wir mal an, in /var/allegro liegen acon und dawa.flx, in
/var/data/katalog liegt die Datenbank xyz mit m.cfg, d.h. dort liegt
auch eine xyz.log

Dann startet man in /var/allegro so:

./acon -jdawa.flx -d/var/data/katalog -bxyz -km /var/data/katalog/xyz.log

  anstatt   log2alg /var/data/katalog/xyz.log
   (dabei käme aber xyz.adt raus, das müßte man umbenennen in xyz.mdt!)

und kurz darauf kommt die Erfolgsmeldung:
   Das war's, Datei /var/data/katalog/xyz.mdt ist fertig

Diese Datei xyz.mdt läßt sich in eine andere m-Datenbank oder eine
Sicherungskopie ganz normal mit  update.job  und -uPFAD/xyz.mdt -fm11
einmischen.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20181218/7701288e/attachment.html>