Prüfroutine um Duplikate zu vermeiden

[DerGecko]

Guten Morgen zusammen,
ich benötige für eine Notes DB zur Verwaltung von Projekten eine Prüfroutine, um den Sachbearbeiter auf ein evt. schon angelegtes Projekt mit gleicher Nummer aufmerksam zu machen.
Da die Projektnummern aus der Warenwirtschaft übertragen werden, ist eine manuelle Eingabe nötig.

Nun habe ich die Eingabevalidierung der Projektnummer über eine Formel prüfen lassen:

Code

_View := "Alle";
_Key := Projeknummer;
_Col := 1;
_Lookup := @DbLookup("":"NoCache";"";_View;_Key;_Col);

@If(@IsError(_Lookup);
@Success;
  @Elements(_Lookup ) = 1 & _Lookup  = @Text(@DocumentUniqueID); @Success;
 @Failure("Ein Projekt mit dieser Projektnummer ist bereits vorhanden!")
)

Die Validierung findet nun aber auch bei schon angelegten Projekten statt und die Projektnummer wird als schon vorhanden gemeldet.
Wie sollte ich die Formel sinnvoll erweitern damit z.B. @isnewdoument die Prüfung eingrenzt auf Prüfung bei Neuanlage?

Oder hat jemand einen anderen Ansatz mit einem Skript, welches in dieser Form ja des öfteren zum Einsatz kommen dürfte? Kann man vieleicht sogar auf eine interne Funktion zurückgreifen, um die eindeutigkeit von Werten zu gewährleisten?

Sonnige Grüße und vielen Dank an die erfahrenen Helfer,
Mario

[BigWim]

Code

@if (@IsNewDoc;"Prüfung notwendig";@Return("schon geprüft"));

_View := "Alle";
_Key := Projeknummer;
_Col := 1;
_Lookup := @DbLookup("":"NoCache";"";_View;_Key;_Col);

@If(@IsError(_Lookup);
@Success;
  @Elements(_Lookup ) = 1 & _Lookup  = @Text(@DocumentUniqueID); @Success;
 @Failure("Ein Projekt mit dieser Projektnummer ist bereits vorhanden!")
)

Oder Du setzt Dir ein Kennzeichen im Document. Wenn der Wert z. B. 1 ist, braucht nicht mehr geprüft werden. Hängt natürlich von Deiner Anwendung ab, aber dann wärst Du etwas flexibler, falls mal eine "nachträgliche Prüfung" stattfinden sollte. Einfach den Wert auf 0 zurückstellen und beim nächsten Mal wird wieder geprüft ....

Code

@if (<MeinFeldname> != 1;"Prüfung notwendig";@Return("schon geprüft"));

Markus

[ascabg]

Hallo,

Und das ganze wird dann noch schoener, wenn die Db auf verschiedenen Servern liegt. (also die Replikation mit ins Spiel kommt)

Andreas

[DerGecko]

Danke für den Tipp BigWim! Ich bau meine Formel mal so um, dass nur bei neuen Dokumenten geprüft wird. @Return lasse ich dann mit dem null string "" einfach leer laufen, damit nach der Validerung gespeichert wird.

Genau das von ascabg angesprochene Problem habe ich allerdings zudem....
Es muß doch ein gescheites und schon existentes Konzept geben, wie ich Duplikate vermeiden kann... manchmal feheln mir in Notes einfach elementare Funktionen, die in anderen DB Systemen selbstverständliche Boardmittel sind... 

[ascabg]

Na dann viel Spass dabei.

Aber eventuell hilft Dir dies hier noch etwas weiter.
eindeutige Nummer

Andreas

[DerGecko]

Das wäre eine pfiffige Lösung, wenn ich hier irgendeine eindeutige Nummer generieren müßte.

>> Ich möchte aber prüfen, ob die vorgegebene Projektnummer aus der Warenwirtschaft schon vorhanden ist, um dies zu melden und eine Doppelspeicherung zu verhindern:

"Achtung, dein Projekt wurde schon eingetragen - Nummer existiert bereits!"

[BigWim]

Es muß doch ein gescheites und schon existentes Konzept geben, wie ich Duplikate vermeiden kann...

Ich eine Universallösung wirst Du nicht finden. In Deinem Fall sehe ich zwei mögliche Wege, die aber im gesamten Umfeld betrachtet werden müssen, was von dieser Seite der Tastatur schwierig ist

a) eine zentrale Datenbank, in der Du die Dokumente sammelst und gegen diese DB die Abfrage machst

b) eine ständige Prüfung der Eindeutigkeit mit unterschiedlichen Hinweistexten:
bei Neuanlage: Bereits erfaßt
bei Änderung: Achtung, xy verwendet Ihre Projektnummer. Dokument bis zur Klärung gesperrt

oder so ähnlich

Markus

[Peter Klett]

... manchmal fehlen mir in Notes einfach elementare Funktionen, die in anderen DB Systemen selbstverständliche Boardmittel sind...

Ich kenne kein DB-System, dass an verschiedenen Standorten, oder sogar offline, betrieben werden kann und eine Eindeutigkeit eines Schlüssels ohne vorherigen Datenabgleich garantiert.

Wenn Du die Funktionen solcher Systeme erwartest, musst Du die Datenbank auch so nutzen, wie die anderen Systeme, nämlich zentral auf einem Server.

Bei verteilter Nutzung würde ich die Nummernverwaltung zentralisieren, also eine zentrale DB, in der zu jeder vergebenen Nummer ein Dokument geschrieben wird, gegen diese DB lässt Du die Prüfung laufen. Diese Datenbank kann ganz klein sein, und daher auch bei schlechter Anbindung noch schnell genug (eine Maske, ein Feld, eine Ansicht). Ist diese zentrale Datenbank nicht erreichbar, kann kein neues Dokument erstellt werden. Wobei Du Perfomance sparen kannst, indem Du erst innerhalb der dezentralen Projekte-DB nach der Nummer suchst, ist die dort bereits vorhanden, sparst Du Dir die Suche in der zentralen Nummern-DB.

Vergiss nicht, dass bei Löschungen von Dokumenten auch die zentrale DB aktualisiert werden muss.

Bei fehlender Verbindung der Clients zum zentralen Server wäre auch eine Überprüfung per Mail möglich. Zentral benötigst Du dann eine Mail-In-Datenbank, in die Anfragen zum Vorhandensein der Nummer gesendet werden. Ein Agent in der DB empfängt die angefragte Nummer, sammelt die in einer zentralen Nummerndatenbank und sendet ein OK oder Nicht OK an die dezentrale Mail-In-Datenbank des Standortes zurück, aus dem die Anfrage kommt. Dieses OK oder Nicht OK wird der dezentralen Replik der Projekt-DB in irgendeiner Weise zur Verfügung stellt.

Sollte eine Zentralisierung der Nummernüberprüfung nicht möglich sein, kannst Du die Eindeutigkeit beim Erstellen der Dokumente nicht garantieren, mit keinem System. Da hilft dann nur noch eine nachträgliche Überprüfung, die Dokumente mit doppelt vergebenen Nummern separat ausweist.

[pram]

Welche Anforderung hast du denn an die Nummern?

- Wenn die Nummern nicht zwangsläufig fortlaufend sein müssen und Lücken enthalten dürfen
könntest du in Filiale A alle geraden Nummern und in Filiale B alle ungeraden Nummern nehmen.

- ggf kannst du auch irgendwo einen kleinen Webservice ablegen (muss nicht mal unter Notes laufe) bei dem man eine Nummer "ziehen" kann.

Ansonsten, was spricht gegen @unique oder die UNID eines Dokumentes?

Gruß
Roland

[Peter Klett]

Ansonsten, was spricht gegen @unique oder die UNID eines Dokumentes?

Es gibt die Nummern schon in einem anderen System (Warenwirtschaft)