AtNotes Übersicht Willkommen Gast. Bitte einloggen oder registrieren.
22.09.20 - 19:33:31
Übersicht Hilfe Regeln Glossar Suche Einloggen Registrieren
News:
Schnellsuche:
+  Das Notes Forum
|-+  Domino 8 und frühere Versionen
| |-+  Entwicklung (Moderatoren: Axel, eknori, Hoshee, ata, Thomas Schulte, koehlerbv)
| | |-+  Laufende Nr. die 1000ste
« vorheriges nächstes »
Seiten: [1] Nach unten Drucken
Autor Thema: Laufende Nr. die 1000ste  (Gelesen 4349 mal)
TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« am: 16.12.03 - 22:02:15 »

Hi,

laufende Nummer wird ja immer wieder mal diskutiert. einfach mal Suche nehmen und "laufende" eingeben, unten auf 1000 Resultate einstellen.

Was ich hier u.a. nicht diskutieren möchte:
 - warum muss die fortlaufend sein, es reicht doch eindeutig
 - warum lässt Du die nicht immer erst nachts per Agent zuweisen

Grundsätzliche Überlegung von mir:
 - wenn lokal gearbeitet wird: no way, dann darf auch keine vergeben werden, erst nach Replizierung auf dem Server (wie soll man das sonst steuern)
 - es gibt ja wohl die Möglichkeit einen Agenten zu blocken, wenn der gerade von einem anderen User ausgeführt wird. Wäre evtl. ein Ansatz. Nur: Wie weiß Server A dass der Agent auf Server B gerade geblockt ist?

Daraus resultierend hab ich auch unter Tipps und Tricks die Sandbox-DB gepostet, die zumindest auf 1 Server alleine sauber arbeiten soll...?

Weitere Ideen / Anregungen sind wünschenswert :-)

TMC

P.S. Es sollen mehrere User mit der DB arbeiten, ein Lookup in einer View ob Nummer bereits vorhanden klappt da wohl leider nicht.
Hab auch jetzt erst gehört, dass ein Schreiben der aktuellen Nr. in ein Profildok Probleme machen kann (weil nicht immer gleich refreshed, sondern das Profildok u.U. noch in einem Cache liegen soll?)
Gespeichert

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

Lossa
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 1401



WWW
« Antworten #1 am: 16.12.03 - 22:38:21 »

Hab auch jetzt erst gehört, dass ein Schreiben der aktuellen Nr. in ein Profildok Probleme machen kann (weil nicht immer gleich refreshed, sondern das Profildok u.U. noch in einem Cache liegen soll?)

Genau so ist es, die Profildokument sind gecached und genau deshalb ist es so toll langleebige Informationen schnell im Zugriff zu haben, aber bei häufigen Änderungen gibts arge Probleme und wenn du zu viele Profildokumente erzeugst auch.
Gespeichert

Viele Grüße

Ulrich-Thomas Lossa
Aktiv als Notes Admin und Entwickler seit Version 1.
Freier Trainer und Berater.
Zertifiziert für alle Versionen SA und DB.
IBM Certified Advanced Application Developer (PCLP AD)
IBM Certified Advanced System Administrator (PCLP SA)
IBM Certified Instructor for System Administration and Application Development ( CLI)
IBM Certified Instructor for Websphere Software
IBM Certified Instructor for DB2
http://www.alphatrain.de
Lossa@alphatrain.de
TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #2 am: 16.12.03 - 22:54:04 »

ok, danke für den Hinweis bzw. die Bestätigung, Lossa.

Ich kopiere mal den Posting-Inhalt vom anderen Thread hier rein, passt gut dazu  Smiley
---------------------------------------------------------------------------
koehlerbv am 16.12.03 um  22:43:40
Zitat
Würde mich nämlich interessieren, ob es überhaupt möglich ist, bei 17 Serverrepliken immer binnen Milli-Sekunden laufende Nr. zuordnen zu lassen (und die Zuordnung nicht auf Nachts auszulagern) - die es dann auch immer nur einmal gibt.
Das ist nicht möglich. Völlig ausserhalb des Prinzips "Notes". Eindeutige Schlüssel - das geht sich ohne weiteres. Fortlaufende Nummern & Notes ist wie Bohlen & Literatur oder USA & Völkerrecht oder Outlook & Virenschutz oder ...

Dem von Dir angelegten Thread werde ich gerne folgen und möglichst Beiträge liefern, denn: Gehen tut immer was. Man muss eben nur Notes bzw. der Aufgabenstellung (da könnte dann Notes hinten 'runterfallen) genügen.

Schon gespannt ist
Bernhard
---------------------------------------------------------------------------

TMC
Gespeichert

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #3 am: 16.12.03 - 23:04:09 »

OK, mal überhaupt: warum das ganze:

Es gibt ja im Geschäftsleben immer Vorgänge.
- Bearbeitung von Anträgen
- Bearbeitung von Reklamationen
u.v.m.

Da ist es leider heute immer noch erforderlich, Original-Dokumente in Leitz-Ordnern abzulegen (da ja nicht überall immer Scanner verfügbar, weil Verträge, etc.).
Hier bewährt sich einfach eine laufende Nummer. Die Leitzordner sind dann z.B. so beschriftet:
 - 10000-10100
 - 10100-10200
etc.

Vorteil: Man findet asap das gewünschte Dokument, unabhängig wer an dem Fall gearbeitet hat. Man kann diese Nr./Referenz auch überall mit angeben und hat immer einen Bezug.
Wenn jetzt bei der Nummernvergabe mal ein 10er Block oder so nicht vergeben wird: nicht tragisch. Wenn doppelte Vergabe: tragisch.

Wenn hier jem. einen völlig anderen Ansatz hat: --> ich bitte darum  Smiley

TMC
Gespeichert

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

TMC
Freund des Hauses!
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 3660


meden agan


« Antworten #4 am: 16.12.03 - 23:10:31 »

Ist noch ziemlich theoretisch, wäre aber vielleicht ein Ansatz:

Nummernkreise pro Tag und Server vergeben.

Dabei eine nette Formel:

"Anzahl neuer Dokumente der letzten xx Tage auf Server A" dividiert durch  "xx Tage" plus  "Sicherheitsaufschlag y"

Gespeichert

Matthias

A good programmer is someone who looks both ways before crossing a one-way street.

Semeaphoros
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 8152


ho semeaphoros - agr.: der Notesträger


WWW
« Antworten #5 am: 16.12.03 - 23:26:47 »

Profildokumente können mit ihrem Caching-Mechanismus tatsächlich ein Problem darstellen. Vermutlich lässt sich das aber in diesem Falle umgehen, weiter unten darüber.

Nachschauen in einem View ist tatsächlich unzweckmässig, da bei der nichthierarchischen Netzwerkstruktur, die Domino schlussendlich bildet, nicht sichergestellt ist, dass alle Dokumente auch tatsächlich immer vorliegen.

Damit es zuverlässig läuft, muss der Prozess - notesuntypisch - an einen bestimmten Server gebunden werden.

Damit gibt es immer noch 2 unterschiedliche Ansätze:

A
Die Nummern werden nur vom Server über einen Agenten vergeben (egal ob periodisch oder angestossen durch neue/geänderte Dokumente). Dadurch ergibt sich zwar eine Verzögerung in der Nummernvergabe, aber es ist relativ einfach sicherzustellen, dass die Nummern sequenziell vergeben werden. In diesem Szenario ist es ziemlich unwesentlich, ob der Zähler in einem normalen Dokument, in einem Profil-Dokument oder direkt aus einer Ansicht ausgelesen werden.

B
Die Nummern werden von Clients vergeben. Dabei dürfen diese nur vergeben werden, wenn der Client direkt auf dem designierten Nummerierungsserver arbeitet. In diesem Fall sollte der Zähler in einem dedizierten normalen Dokument abgelegt werden, hier wirkt sich das Caching-Problem der Profildokumente sonst aus. Hier haben wir dann auch die Situation, dass mehrere Prozesse gleichzeitig Nummern anfordern bzw. vergeben können. Damit ist a) sicherzustellen, dass Nummern nicht doppelt und b) keine Löcher im Käse entstehen. Für beides gibt es Strategien: Wird ein neues Dokument erstellt, wird entweder bis zum Speichern keine Nummer oder nur eine provisorische Nummer vergeben. Nach dem Speichern wird ein Abbrechen/Löschen verboten. Oder, man vergibt die Nummer grundsätzlich erst beim Speichern.

So long
Jens
Gespeichert

Jens-B. Augustiny

Beratung und Unterstützung für Notes und Domino Infrastruktur und Anwendungen

Homepage: http://www.ligonet.ch

IBM Certified Advanced Application Developer - Lotus Notes and Domino 7 und 6
IBM Certified Advanced System Administrator - Lotus Notes and Domino 7 und 6
ata
Moderator
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 5092


drenaiondrufflos


WWW
« Antworten #6 am: 18.12.03 - 00:51:47 »

... ich habe mehrfach mit sequentiellen Nummern gearbeitet. Profildokumente eignen sich nur dann, wenn ich alleine in dieser DB arbeite - ansonsten wegen Cache absolut kein Weg...

... in meinen Datenbanken habe ich zwei Wege:

1. Konfig-Doc mit der aktuell zu vergebeneden Nummer. Pro Server wird in der Nummer ein Serverkennzeichen vergeben. Damit kann es auf einem Server keine doppelten Nummern geben.

2. In einer Ansicht nach der höchsten Nummer suchen und dann einen Zähler hochzählen. Für die Server wird ebenfalls ein Konfig-Doc benötigt, in welchem ich die Nummer speichere.

Ohne Serverkennzeichen kann nur dann gehen, wenn ein bestimmter Server jederzeit und von jedem Ort erreichbar ist - Ausnahmen müssten dann eben zurückgestellt werden und per Agent nachbenannt werden.

Da Notes keine Echtzeitdatenbank ist, kann man die Vergabe der Nummer auch über eine ASCII-Datei erzwingen. Sie darf zur Bearbeitung nur durch eine Person geöfnet werden.

... so ein grober Überflug - es gibt hier im Forum bereits einige Beiträge, an denen ich beteiligt war. Ein Beispiel für eine sequentielle Nummernvergabe per Konfig-Doc wurde mal von Doliman ins Forum gestellt...

ata
Gespeichert

Grüßle Toni Smiley
Seiten: [1] Nach oben Drucken 
« vorheriges nächstes »
Gehe zu:  


Einloggen mit Benutzername, Passwort und Sitzungslänge

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines Prüfe XHTML 1.0 Prüfe CSS
Impressum Atnotes.de - Powered by Syslords Solutions - Datenschutz | Partner: