AW: AW: [Allegro] Dateigröße

[Panski, Regine]

Lieber Herr Berger,
das ist mir alles einleuchtend. Die wohl beste Variante ist die , von nun an festzulegen, das neue Sätze in Datei 2 kommen.

Mit dem "aufbohren" haben Sie recht: Nach Setzen von ii=2 in der Indexparameterdatei und Datenbankneuaufbau, kann man komischerweise in a99 alles sehen. Unter Cockpit -> benutzen kommt die Meldung "Kein Eintrag unter dieser Satznummer oder fehlerhafte Satznummer". Das mache ich wieder rückgängig.

Bisher mache ich ein Update nach dieser Variante (Datums-Volltextsuche) , aber nur in eine Datenbank mit lesendem Zugriff. Das funktioniert alles bestens.

Wo sehen Sie das Problem, das auch bei 2 Datenbanken mit schreibendem Zugriff zu machen? Beide Datenbanken haben unterschiedliche Ident- und Bestellnummern. Hätten Sie eine andere Idee?

Viele Grüße


Regine Panski
Kammergericht-Bibliothek
Elßholzstr. 30-33
10781 Berlin
(030) 90152411


> -----Ursprüngliche Nachricht-----
> Von: allegro-bounces at biblio.tu-bs.de [mailto:allegro-bounces at biblio.tu-
> bs.de] Im Auftrag von Thomas Berger
> Gesendet: Freitag, 17. Februar 2006 11:40
> An: Allegro-C Diskussionsliste
> Betreff: Re: AW: [Allegro] Dateigröße
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Liebe Frau Panski,
> 
> > es ist wohl doch so, dass die Daten anhand einer Art Volltextsuche
> > eingespielt werden (Handbuch Kapitel 9.1  S. 156 : -N  Fürj=2
> > (default) gilt: nur in die mit Option -n gewählte Datei speichern).
> 
> Mir ist nicht ganz klar, was Sie sagen wollen, eine Aussage mit
> "nur in Datei ... speichern" ist aber nie richtig:
> 
> - - Wenn die Daten via #u1 sagen, dass sie ein Neusatz sind, werden
>   sie in die in #u1 genannte Datei gespeichert, falls voll in
>   die naechste etc.
> - - Wenn die Daten aufgrund von -fm01 oder Primaerschluesselvergleich
>   als Neusatz erkannt werden, gehen sie in die ueber den Schalter
>   -n spezifizierte Datei, falls voll in die naechste etc.
> - - Wenn die Daten bereits vorhanden sind, aber umgespeichert werden
>   muessen, landen sie (bei -N1 in einer tendenziell beliebigen Datei,
>   sonst) am Ende der Datei, in der sie standen, falls voll in der
>   naechsten etc. Schalter -n ist hier unabhaengig von -N stets ohne
>   Belang.
> 
> (Bitte korrigiere mich jemand, falls hier etwas nicht stimmen sollte)
> 
> > Da ich vorhabe von Datenbank A nach B und dann auch von B nach A
> > Updates zu machen scheint mir das riskant.(In A und B wird
> > katalogisiert) Ich werde lieber den Wert in der Indexparameterdatei
> > hochsetzen. Oder sieht das noch jemand anders?
> 
> Kreuz- und Quer-Updates sind immer riskant, vor allem solche, die
> die Kandidaten mit Datumsstempeln heraussuchen. Insbesondere solche,
> die das auch noch per Volltextsuche probieren.
> 
> M.W. ist "aufbohren" keine Option fuer jene, die noch mit DOS-ORDER
> oder DOS-ALF auf ihre Datenbank zugreifen wollen.
> 
> viele Gruesse
> Thomas Berger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFD9agGhKFJT0F1FsoRAnWVAJ4zbPWe9L8amb+hdtO1ooOKkTBfmwCfWb8h
> hMd2QjmBZRL1+ZQHR+/soEE=
> =C52c
> -----END PGP SIGNATURE-----