Update und Primaerschluessel

[Klaus Lehmann]

 HK> Hier also die Geschichte: eine Bibliothek mit zwei Standorten soll 
 HK> regelmaessig ihre Bestaende per Diskette austauschen. Um getrennte
 HK> und   eindeutige Primaerschluessel fuer ein Update zu erhalten habe
 HK> ich schon   beiden Standorten unterschiedliche Ident-Nummern
 HK> zugeteilt. Bei einem   Update mit -fm11 habe ich aber bisher eine
 HK> ganze Anzahl von Doubletten   erhalten, was mich schon erstaunte.
 HK> Angeregt durch eine Reihe von Postings in den letzten Tagen habe
 HK> ich nun   den Primaerschluessel nach dem Handbuch-Vorbild (V14, S.
 HK> 144) verlaengert   - der Schluessel wird nun aus #90, #91 und #87
 HK> gebildet - und die Update-  Prozedur wiederholt.
 HK> Das Ergebnis war aber wieder eine Anzahl von Doubletten; ausserdem
 HK> wurden   neue Ident-Nummern erzeugt.

hallo herr kamke

einige ideen und anregungen zu Ihrem update-problem.

-fm11 ist unschon.
ich benutze -fm21. so erhalte ich aus dem 'fremden' bestand genau(?)
die satze, die dem originalbestand fehlen.
(in der doku muss eine genau erklarung zu den fm-para's stehen ;-)
 
meine batch:
update -fm21 -n4 -kakbg -dm:\neu\kbg -um:\alt\y.alg -m1 -v0 -h0 -L 
         ~            ~ fremdbestand
                        originaldatenbank

mit fm21 geht es evtl besser...

ein zweiter (heisser?) tip ist -n4
nehmen wir mal an, sie haben keine datenbank_4.
also wird der zu updatende bestand genau in diese nummer reingeschrieben!

genial? ;-)
naja... ;-)  es hat den (unschatzbaren) vorteil, dab sie mit einem einem
viewer oder editor (s.a. die diskussion um die editierbarkeit von alg's/ald's
;:-)   reingucken konnen. Sie haben exact die NEUE Menge der Satze vorzuliegen,

die NEU reinkommen.

obige losung ist nicht fur die ewigkeit! sie hat den nachteil, dab man n4 immer
VORHER leereren muss (neuindexieren etc!) usw usw. SEHR abeitsaufwendig!
aber: DER Vorteil: der update-vorgang ist ABSOLUT kontrollierbar!

eine weitere anmerkung zu Ihrem Primar-Schlussel.
#90, 91 und 87 sind mir logo unbekannt.
warum so kompliziert?

ware da nicht eine isbn-nummer angenehmer?
oder eine barcode-nummer, mit der man die exemplare 
eineindeutig unterscheiden tut. ?

Prinzipiell ist mir das update-Verfahren zu 'unsicher'.
Es ist immer(?) eine SEHR verzwickte Angelegenheit, ZWEI Datenbestande zu
verwalten, die beide eine wie_immer_auch_geartete Schnittmenge haben.
(UM diese menge geht es ja bei update;-)

Vielleicht sollten Sie IHRE (Daten-)Organisation SO andern, dab Sie auf das
update NICHT mehr angewiesen sind. (?!)

Vielleicht mal kurz meine Losung des Problems:
Die main_Datenbank 'kbg' liegt in der Hauptstelle der Stadtbibliothek
Kreuzberg. da HIER alles netzwerkmabig erfasst ist, gibt es kleine Probleme
bei der Datenhaltung. (sagen_wir_mal: 'fast' keine ;-)

Es gibt zwei Zweigstellen, die sogenannte 'retro-Daten' erfassen. Sie hangen
an keinem Netz dran. Also haben wir das klassische Addidas-Netzwork hier. ;-)
In den Zweigstellen werden Alt-Bestande erfasst. Also Bestande, die in der 
Hauptstelle NICHT vorhanden sein konnen (sorry, fur die -zu- ausfuhrliche
Erklarung)

Ich habe die dortige Datenbank, bzw den Index SO aufgebaut, dab jeder
retro-datensatz mit einem aktuellen Datumseintrag versehen wird (und das
z.b. im extra-Register 10)
12  961131
14  961201
15  961205
21  961210   am 10.12.1996 waren die Kollegen besonders fleissig: 21 Titel!
             alles klar?

Mit einer export-routine (evtl pa.apr?) wird in EINE Datei reingeschrieben.
Vorher naturelement werden die Tage markiert, die exportiert werden sollen.
Diese nennen wir mal dud.alg   (nach der Zweigstelle Dudenstrasse)
die dud.alg wird mittels update [aber OHNE Primarschlusselgemurkse! in die
ECHTE Datenbank reingespielt. garantiert bekomme ich so keine Doubletten!
voila. ;-)

Das ware der ungefahre Aufbau. Hinter den Coulissen passiert noch einiges 
Anderes, DAS soll aber nicht interessieren.

evtl EINE Losung?


hoffe, geholfen zu haben


Viele Gruesse
 Klaus
  Lehmann
   Sysop of Novell-Servers in Kreuzberg 
--- timEd/2 1.10+
--
|Internet: lehmann at fg.arco.met.fu-berlin.de
|Fidonet:  Klaus Lehmann 2:2411/801.502