[Allegro] Datums(?)-Unterschiede

[Fischer, Thomas]

Hallo Herr Eversberg,

> Am 08.02.2017 um 08:44 schrieb Bernhard Eversberg <b-eversberg at gmx.de>:
> 
>> Gesendet: Dienstag, 07. Februar 2017 um 15:19 Uhr
>> Von: "Fischer, Thomas" <fischer at sub.uni-goettingen.de>
>> 
>> ich habe mal wieder Probleme mit globalen Ersetzungen. Die Ersetzung funktioniert schon, aber beim Versuch, die veränderten Daten zu speichern, bekomme ich die Meldung
>> 
>> ---------------------------
>> a99
>> ---------------------------
>> Date diff: 








































ridge, ¨°9ersity P¸„´ÂŠ­Ðþ9ßþ9îþ9ÿ9$ÿ9Jÿ9Rÿ9˜:c:Ö:!:*:4:7:67:c7:i7:r7:8:8:ischer / 20170111/18:11:23-26347/28948
>> ---------------------------
>> OK
>> ---------------------------
>> 
>> die mich vermuten lässt, dass da mehr als ein Datum nicht passt. (Vor dem "ridge" stehen noch 61 ASCII 1 und ein ASCII 3, die man im Mailformat wahrscheinlich nicht sieht.)
>> Wie gehe ich da vor?
>> 
> 
> Das Einfachste: Ganze Datenbank neu aufbauen. Die neue ist dann frei von solchem Schrott.

das werde ich bei Gelegenheit machen, dauert aber wohl ein Weilchen, so dass es jetzt nicht passt.
Allerdings weiß ich nicht, ob ich außer besagtem Schrott noch andere Daten verliere (siehe meine Mail vom 1.2.).
> 
> Wichtiger ist aber doch die Frage: Wie konnte es dazu kommen?
> Mangels Information über die Vorgeschichte und näheren Umstände, besonders die Einzelheiten
> der Ersetzungsaktion, samt Zustand der fraglichen Sätze vor der Aktion, ist mir keine
> weiterführende Aussage möglich. Ideal wäre, aber wem sage ich das, man könnte das
> Phänomen reproduzieren.

Tja, so ist die Situation oft.
In diesem Fall habe ich ganze Felder geleert, in denen spezielle URLs standen.
Suche nach: http://jfm.uni-goettingen.de/$
Ersetzung leer
in Feld #21
Globale Ersetzung in einer passenden Ergebnismenge, ausgewählt nach Indexeinträgen mit diesem URL-Anfang.
Damit wurde der ganze Inhalt dieses Feldes gelöscht, beim Speichern verschwand es dann.
Dieser Prozess des Speicherns brach dann mit obiger Meldung ab.


Aktuell noch eine weitere Frage:
Ich habe ein Update mit A99 mit der Einstellung 40 durchgeführt:
#uX9x set u40\update gallica.gdt
Die Einträge in der Datei gallica.gdt waren von der Art

#05 54.0773.03
#26 %tC. R.%v186%p1691-1694%y1928%u(1928)
#06g12148/bpt6k3139f/f1693.image

Dabei liefert #05 den Primärschlüssel, #06g ist eine neu hinzugefügte Kategorie und #26 ist schon vorhanden, in der Datenbank hängt aber noch eine URL daran, die mit diesem Update entfernt werden sollte.
Bei dem Update wurde aber nur #06g ergänzt, #26 bleib unverändert.
Bei einem zweiten Update (ohne #06g) wurde #26 wie gewünscht ersetzt.

Dieses Verhalten kann ich mir nicht erklären.

Mit freundlichen Grüßen
Thomas Fischer

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 842 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20170208/6f9c1b31/attachment.sig>