ORDER: Bestellnummern; UPDATE: Kein Ersatz

[Ralf Matalla]

Liebe Frau Koczian,

>                                                                   Gemerkt haben wir das immer
> erst hinterher an den zu niedrigen Nummern, deshalb ist es mir noch
> nicht gelungen, den Hergang zu rekonstruieren. 
Mir leider auch nicht. Tatsache ist nur, dass der Generator sich 
gelegentlich vervielfacht. Es haengt auf jeden Fall irgendwie mit den 
Abstuerzen zusammen - und mit einem gesperrten Generator (da gibt es 
ja dann so eine Frage 'nochmal versuchen'). 
Normal stoeren die mehrfachen Generatoren gar nicht: das Programm 
nimmt den ersten; wenn das der richtige ist: prima. Aber manchmal 
sind die Nummern falsch...

> Noch eine Frage zu ORDER: Kann es Schaden anrichten, wenn man dem
> Bestellnummerngenerator ein zusaetzliches Teilfeld anhaengt (um zu
> sehen, ob es bei der Verdopplung mitkommt, und falls nein, um den
> richtigen Satz schneller zu identifizieren).?
Glaub' ich nicht, dass das schadet.
> 
> 2. UPDATE: Ebenso sporadisch findet im Modus -fm11 nicht jede
> Ersetzung statt, die stattfinden muesste, es werden Saetze mit
> bereits vorhandenem Primärschluessel zusätzlich eingemischt. Das
> Problem hatten wir immer schon, behoben ist es nach wie vor nicht.
> Abweichende Indexparameter werden bei den UPDATE-Aktionen, um die es
> hier geht, nicht benutzt.
Haben die Schluessel evtl. einen Punkt am Ende?
> 
> - Kann es ueberhaupt an fehlerhaften Parametern liegen, wenn ja,
> welche Bereiche sind verdaechtig?
Grundsaetzlich ist das Speicherproblem ein Problem; dann koennte es 
evtl. noch ein Geschwindigkeitsproblem sein. Ich habe versucht, die 
cat.api zu verschlanken (es gibt da ja vieles, was in einer 
Erwerbungsdatenbank nicht gebraucht wird): das bringt Speicher und 
vielleicht etwas Tempo.
Und: regelmaessiges Neuindexieren verbessert die Geschwindigkeit 
erheblich. Die DB scheint sich auch stark aufzublaehen, weil bei 
jeder Bestellung der Titelsatz geaendert wird (#9C und Aenderungs-
datum), bei jedem Inventarisieren auch noch der Bestellsatz: i.a. passt 
dann der Satz nicht mehr an die alte Stelle und wird umgespeichert.
Ich werde jetzt mal probieren, ueppig Platz zu lassen in den Saetzen: 
ich dachte an 30 Zeichen fuer das Aenderungsdatum (8 Datum, 8 
Uhrzeit, 8 Bearbeiter + Trennzeichen + Kat.),20 Zeichen fuer das 
Inv.datum in 9DA (8 Datum, 8 Bearbeiter, ...) 10 Zeichen fuer das 
Inv.datum in 9DB: das sind zusammen 60 Zeichen, 50 mehr als jetzt
Bei insges. 280.000 Datensaetzen im Moment kommen also fast 14 MB 
dazu. Na ja, bei 75 MB Daten, 20 MB Kurztitel und 70 MB Index ist das 
zu verschmerzen.

Gruesse
*********************************
Ralf Matalla
Universitaets- und Landesbibliothek Duesseldorf
Fachref. Mathematik u. Datenverarbeitung
Universitaetsstr. 1
40225 Duesseldorf

Tel.: ++49 211 81-13527
Fax:  ++49 211 81-13054