[Allegro] Antwort: Re: Antwort: Re: Datensatz über "Zack" importiert und beschädigt

Norbert.Kaut at stadt.mainz.de Norbert.Kaut at stadt.mainz.de
Fr Jun 13 10:11:04 CEST 2014


Von:    Bernhard Eversberg <ev at biblio.tu-bs.de>
An:     Allegro-C Diskussionsliste <allegro at biblio.tu-bs.de>, 
Datum:  13.06.2014 09:23
Betreff:        Re: [Allegro] Antwort: Re:  Datensatz über "Zack" 
importiert und beschädigt
Gesendet von:   "Allegro" <allegro-bounces at biblio.tu-bs.de>



Am 12.06.2014 20:05, schrieb Norbert.Kaut at stadt.mainz.de:
>
> Ich arbeite tatsächlich noch meistens mit Presto, da mir die tägliche
> Arbeit damit schneller von der Hand geht. Die beiden jüngeren
> Kolleginnen benutzen aber a99 für die Katalogisierung in die gleiche
> Datenbank!
Und welches PRESTO? 

Presto.exe und update.exe haben das gleiche Datum:

Datum:   28.04.2011
>
> Allerdings nutzen diese auch noch die altbewährte Zack-Importroutine für
> Einzeldatensätze im MAB-Format über eine "Zack.bat"-Datei aus der Zeit
> als wir nur Presto hatten. (Eingerichtet damals von Fr. Dr. Guckler aus
> Darmstadt, die längst im Ruhestand ist)
Dabei kommt das alte UPDATE.EXE zum Einsatz. Von wann ist das?
Es hatte seinerzeit dieselben Macken wie PRESTO, als es die besagten 
Fehler gegeben hat. Der jetzt aufgetretene Fehler wurde ganz sicher von 
UPDATE verursacht. Mit V34.2 wird acon verwendet und der Job update.job,
was bedeutet, daß die Prozeduren zum Speichern identisch sind mit denen
von a99.
Einsatz von V34.2 ist dringendst zu empfehlen, Weiterarbeit mit älteren
Versionen von PRESTO und UPDATE geschieht immer mit der Gefahr im 
Hintergrund, daß Probleme drin sind, die wir inzwischen gelöst haben und
in V34.2 nicht mehr auftreten.
Wie schon öfter betont: Es gibt keine Gründe, unbedingt ältere
Versionen einzusetzen, es ist vielmehr davon abzuraten.
Umstellungsaufwand entsteht nicht, wenn man die aktuelle Version
einsetzt, d.h. auch in dieser Hinsicht besteht kein Grund, dies nicht
zu tun.

>
> Es wird sicher höchste Zeit, die neueren Fremddaten-Importmöglichkeiten
> auch mal zu testen.
>
Sie könnten enorm Zeit sparen, und schneller als mit dnb.flx
bzw. srugbv.flx KANN es technisch nicht mehr gehen. Wir kennen
keine Gründe, die zu einem Verzicht zwingen könnten.

> Ganz unten folgt das Ergebnis von:
>
> *1. h check,  "Adressen checken"*
>

Entscheidend sind diese Zeilen:
>
> rec #3644 wrong position 1953814 (in TBL steht: 7284111) TEXT:
> 1026788^@15 Gutenberg-Museum Mainz^@20 Kunsum : die vierte Konkurrenz
> der Kunst

>
> rec #38205 wrong position 7380209 (in TBL steht: 5663505) TEXT:
> 019860^@20 Gustl Stark^@28 ff frxrfc gusti IÖ/44JP YYY.22 geg. /ÂÂr
> tilgende üTi

Besorgen Sie sich also die Sätze 3644 und 38205 aus einem Backup
und kopieren diese dann neu in die Datenbank, nachdem Sie den
Neuaufbau gemacht haben. Dann ist nichts verloren und Sie können
weitermachen. Gefahrlos mit V34.2. und den neuen Methoden.

Viel Erfolg mit V34.2.
B.E.

_______________________________________________
Allegro mailing list
Allegro at biblio.tu-bs.de
http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20140613/479b1702/attachment.html>


Mehr Informationen über die Mailingliste Allegro