Domino 9 und frühere Versionen > Entwicklung

Feld mit fortlaufender Nummer

<< < (3/6) > >>

Rob Green:
joo..die laufenden Nummern...wooo lauuuufen sie denn, woooo lauuufen sie denn hiiin  ;D ;D ;D

Ein Problem mit einem üblichen Zählerdocmechnismus bei Notes darf nicht verschwiegen bzw. übersehen werden: die klassische Racekondition und der Speicherkonflikt.

Eine Racekondition kann dann auftreten, wenn man mit Dbcolumn die letzte vergebene Nummer ausliest und um 1 im aktuellen Neudoc hochzählt. Tut man die Nummer beim Erstellen des Docs auslesen und dann speichern, führt die Verzögerung  zwischen Erstellung und Speicherung dazu, daß in der Zwischenzeit sich jemand die gleiche "letzte" Nummer geschnappt hat. Damit hat man 2 gleiche Nummern+1 am Ende. Ist man cleverer, zieht man sich die letzte Nummer beim Speichern des Docs. Da ist die Spanne von Nummer ziehen und Speichern im Sekundenbereich. Aber, auch da kann die Racekondition zuschlagen, denn Notes kann die Ansicht nicht so schnell aktualisieren, wenn 2 User zur gleichen Milisekunde ein jeweiliges Neudoc speichern. Notes gibt dann dummerweise vor dem nächsten Upfresh des Viewindex die gleiche "letzte" Nummer zurück.

Bei Verwendung eines zentralen Notes Zählerdocs kann es natürlich zu parallelen Schreib/Speicherkonflikten kommen, wenn 2 User im selben Moment auf das Zählerdoc zugreifen.

Die Gefahr kann  je nach Design bzw. Nutzungshäufigkeit der Datenbank gering oder hoch sein, doppelte Nummern zu erhalten. Einige helfen sich damit, einen regelemäßigen Agent laufen zu lassen, der doppelte Nummern bereinigt. Nicht schön, aber immerhin.

Auch replizierende DB´s beherrschen eine einheitliche Nummernvergabe...der Artikel ist auf LDD Today zu finden, bietet aber genau die gleichen Klippen & Hürden letztlich.

Nach wie vor erachte ich - unabhängig was nun eine laufende Nummer bringt - den Ansatz über eine Verwendung einer externen DB mit Sperrindex Mölichkeit zwecks Vermeidung paralleler Schreibvorgänge (zum Ablegen der vergebenen Nummer/n) am besten, um das zentrale Notesproblem hierbei zu umgehen: Notes kennt keinen Sperrindex auf Datensätze. Dies kann übrigens auch eine stinknormale Textdatei auf dem Notesserver sein, die über runonserver Agent beschrieben/gelesen wird.

CrazyCoder:
HEYYO!! 8)

ES HAT GEKLAPPT!!!

DANKE LEUTE!!!  ;D

Gandalf:
Ok - hab jetzt ne einfache Anfängervariante

hab eine Ansicht in der datenbank erstellt, die mir die benutzten Nummern anzeigt.
Ich mache in dem Feld der Maske ein @dbColum und nehme den letzten wert halt +1. Funzt.
@ RobGreen Da ich noch ganz am anfang mit dem Aufbau werd ich deine Angesprochene Problematik auf später verschieben. Ich weis aber um deren Wichtigkeit.  :)

Bye
Gandalf

wflamme:

--- Zitat von: Alex W am 19.02.03 - 09:30:40 ---das mit den fortlaufenden Nummern ist ein heikles Thema. Benötigt werden sie auf jeden Fall, da man bei der Verarbeitung von vielen Daten irgendein unverwechselbares und doch  für alle Mitmenschen halbwegs  sinnvolles Kennzeichen haben sollte.

--- Ende Zitat ---

Die mit @Unique erstellten Kennungen halte ich schon für fast optimal - eindeutig (auch in replizierenden Umgebungen) und passen auch noch ins Kurzzeitgedächtnis.

Wenn ich sehe, was Meckermann und Konsorten an Kundennummern-, Bestell-, Auftragsnummern- etc-Ungetümen vergeben, dagegen ist @unique richtig schlank und schick!

ata:
@Gandalf

... mit dem @DBColumn wirst du an eine Grenze stossen, den der hat eine Kapa-Grenze, die durchaus zu erreichen ist...

... ein Zählerdokument ist unabhängig von der Anzahl der Dokumente...

ata

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete