Shared Field

[koehlerbv]

Chris, ich halte den serverbasierenden Agent sogar für den einzig wirklich gangbaren Weg (back to the centralized roots). Run on server tut aber nicht not. es braucht einen "verantwortlichen Server", und dort sollte das Teil entweder scheduled laufen oder triggered: Wenn Dokumente erstellt oder modifiziert wurden. Echtzeit bekommt man sowieso nicht hin.

Das steht aber alles schon hier im Forum in zahlreichen Postings. Ich sehe aber ein, dass es doch irgendwie immer wieder diskutiert werden muss, da man ja doch nicht alle Beiträge hierzu gleich findet.

Der erste Lösungsansatz muss jedenfalls lauten: Wenn man wirklich (!!!) zwingend fortlaufende Nummern benötigt (!!!): Alles bedenken, Forum durchsuchen, vor allem: Notes / Domino wirklich verstehen (jeder, der das nicht tut, sollte dann eben erstmal bis zur Änderung dieses Zustands die Hände heben). Wenn man dann immer noch auf fortlaufenden Nummern besteht: Eigentlich ist dann die Applikation Notes / Domino falsch ausgewählt.

Bernhard

[LN4ever]

In vielen Fällen, in denen ein Pflichtenheft "fortlaufende Nummern" ausweist, sind eigentlich nur "eindeutige Nummern" gemeint - und auch die müssen nicht zwangsläufig reine Zahlen sein.

Für ein weltweit auf vielen Servern eingesetztes Reklamationssystem habe ich z.B. die folgende Nummerngenerierung verwendet:

njahr:=@Year(@Now);
nmonat:=@Month(@Now);
ntag:=((@Date(@Now)-@Date(njahr;1;1))/24/3600)+1;
nStunde:=@Hour(@Now);
nMin:=@Minute(@Now);
TextNr:=@Text(@Modulo(nJahr;10))+@Right("000" + @Text(ntag); 3)+"."+@Right("0000"+@Text(100*nStunde+nMin);4);
n1:=@Name([CN];@UserName);
Initialen := @Left(@RightBack(n1; " "); 2) + @Left(n1; 2);

Die Letzte Ziffer des aktuellen Jahres, die Tageszahl im Jahr, die aktuelle Uhrzeit in Stunden und Minuten, die Initialen des Mitarbeiters. Davor wird noch ein P für eine Produkt- und ein S für eine Servicereklamation gesetzt. Heraus kommt etwas wie

P-7009.1137 TaFa

Der Erkennungs- und Merkwert für die Mitarbeiter ist hoch. Der Kunde kann an der Reklamationsnummer nicht die Zahl der Reklamationen indirekt ablesen (das sollte man bei allzu sprechenden Nummern durchaus auch im Hinterkopf behalten). Die Anwender kennen die Initialen ihrer Kollegen und sehen sofort an der Nummer, wer diese Reklamation angelegt hat. Sie sehen auch sofort an der Nummer das ungefähre Alter dieser Reklamation. Im Normalfall muß man sich nur eine dreistellige Zahl merken (die 7 gilt ja für jede Reklamation aus diesem Jahr - und es gibt nur wenige Tage, an denen mehr als eine Reklamation eingestellt wird). Wenn mehrere Dokumente am gleichen Tag erstellt werden, kann man diese genau voneinander unterscheiden.

Für den konkreten Anwendungsfall sollte man nach solchen Lösungen eher suchen als sich immer wieder auf die eigentlich unlösbare Aufgabe der fortlaufenden Nummernvergabe zu stürzen.

In 14 Jahren Echtbetrieb gab es keinen Fall einer doppelten Nummer.

Gruß

Norbert

[SD]

Wir haben das in einer Datenbank nach dem Prinzip doppelt hält besser gelöst.

Einmal über ein Dokument (kein Profildokument... Caching hat der Teufel gemacht!), in dem die aktuelle Nummer gespeichert ist. Die wird im Querysave ausgelesen und inkrementiert und wieder reingespeichert. Außerdem haben wir noch eine nach der Nummer sortierte Ansicht von der wir das erste Dokument holen und schauen, ob die neue Nummer auch wirklich größer ist als die größte in der Datenbank.

Damit sind wir seit gut 2 Jahren und bis zu 2000 Dokumenten pro Jahr sehr zufrieden.

[Axel]

@SD

Ich will die Diskussion über fortlaufende Nummerierung nicht nochmal anstossen, aber nur soviel sei gesagt, auch deine Lösung unterliegt den, schon mehrfach angesprochenen, Risiken.


Axel
 

[LN4ever]

Es ist erstaunlich und erschreckend, wie beratungsresistent jemand ist, wenn er sich in den Kopf gesetzt hat, eine fortlaufende Nummer mit Notes zu realisieren.

Die folgenden Punkte sind zwingend erforderlich, wenn es denn tatsächlich gelingen soll:
- alle Anwender vergeben neue Nummern in nur einer Replik (in Repliken auf anderen Servern oder in lokalen Repliken können keine neuen Dokumente mit Nummernvergabe erstellt werden)
- du stellst sicher, daß ein Anwender zur gleichen Zeit nur ein Dokument erstellen kann (z.B. durch Erstellung des Dokuments in einer Dialogbox)
- du stellst sicher, daß für die Ersteller von Nummern keine Leserbeschränkungen auf Dokumente mit fortlaufenden Nummern gibt oder du speicherst die letzte vergebene Nummer in einem separaten leserfeldfreien Dokument und stellst sicher, daß dieses Dokument nie einen Replikationskonflikt hat.

Der Vorschlag, eine vorläufige Nummer zu vergeben und die endgültige Nummer von einem Agenten eintragen zu lassen, der nur auf einem Server läuft, berücksichtigt genau diese Punkte.

Ansonsten bewegst du dich für den Satz "Ich erhalte eine eindeutige fortlaufende Nummer" auf der Skala der Treffsicherheit nur zwischen
"Manchmal", "ziemlich oft" und "meistens".

Die zwei-, drei- oder fünffache "Absicherung" führt bestenfalls zu einer Verschiebung hin zu "Meistens", keinesfalls aber zu einem "Immer".

Wenn dir das reicht, reihst du dich in die lange Schlange derer ein, die das schon vor dir probiert haben - und auch gescheitert sind. Aber dann mußt du dich fragen lassen, wofür du diese Nummer eigentlich brauchst.

Gruß

Norbert

[SD]

Naja, in den meisten Fällen ist es ja nicht so, dass jemandem der Herzschrittmacher stehenbleibt, wenn mal eine doppelte Nummer vorkommt.