Shared Field

[aks]

Hi,
ich habe mir eine CD-Datenbank gebastelt.
Nun möchte ich aber dort noch folgendes drin haben:
Field -> Anzahl gesamt CDs:
Field -> CD-Nummer:

Ich dachte ich mach das evtl. über ein Shared Field aber das funzt net so ganz. Ich will quasi beim erstellen eines neuen Eintrages sehen wie viele CD Einträge befinden sich in der DB (Anzahl gesamt CDs) und dann beim Speichern soll als CD-Nummer die Anzahl +1 genommen werden. Natürlich soll dann die Gesamtanzahl auch aktualisiert werden.

Kann mir jemand nen Tip geben wie ich das recht simpel hinbekomme ?


DANKE
Andi

[koehlerbv]

Mit einem shared field bist Du hier vollkommen auf dem Holzweg - shared fields sind wiederverwendbare Felddefinitionen (einmal definiert und in vielen Masken ohne Neudefinition einsetzbar).
Weiterhin ist ein Feld "Anzahl CDs" in einem CD-Dokument sehr verwirrend und eigentlich nichtssagend. Eine CD-Nummer lässt sich auch anders vergeben (vorausgesetzt, diese DB wird nur von einem einzigen Benutzer verwendet!). Du brauchst eine Ansicht nach CD-Nummer, absteigend sortiert. Diese kannst Du dann mit @Subset (@dbColumn (....); 1) auslesen und für das neue Dokument inkrementieren - siehe DesignerHelp.

Bernhard

[aks]

Hi, danke für die Antwort. Die DB soll von mehr als einem User editiert werden. Kann man dann Deine Fromel hierzu abändern, oder wo liegt das Problem wenn mehr als ein user darauf zugreifen ?
Das Feld Anzahl gesamt CDs hatte ich nur angedacht, damit ich die CD Nummer irgendwie hochzählen kann und noch weiß was der letzte Stand war.

[klaussal]

Altes Thema, nur neuer Mantel: NEIN, es gibt keine vernünftige Lösung zur fortlaufenden Nummerierung.

[Demian]

Hallo,

hatte mal ein ähnliches Problem. Habe das mit Script im Exiting eines Feldes (Jahr) gelöst. Müsstest du halt ein bissie abändern, z.B. den Code im Postopen der Maske oder so.

<sub>Sub Exiting(Source As Field)
   '==========================================================
   'Beim Verlassen dieses Feldes wird automatisch, das Feld lfdNr gefüllt.
   'Hierzu wird in der Ansicht "Ausbildung - Bewerbungen" das eingegebene
   'Jahr gesucht, und die Anzahl der  vorhanden Dokumente für dieses Jahr
   'gezählt. Das Ergebnis wird mit 1 addiert.
   '==========================================================
   'Allgemein
   Dim work As New NotesUIWorkspace
   Dim uidoc As NotesUIDocument
   Dim s As New notessession
   Dim db As NotesDatabase
   Dim view As NotesView
   Dim doc As NotesDocument
   
   'Vergleich
   Dim Jahr As String   
   'Zähler
   Dim i As Long
   Dim i2 As Long
   '==========================================================
   
   Set uidoc = work.CurrentDocument
   
   'eingegebenes Jahr speichern
   Jahr = uidoc.FieldGetText("Jahr")
   If Jahr = "" Then
      Msgbox "Sie müssen das Ausbildungsjahr eingeben, damit die lfd. Nummer berechnet werden kann!",," "
      Exit Sub      
   End If
   
'zu durchsuchende View setzen
   Set db = s.CurrentDatabase
   Set view = db.GetView("Ausbildung - Bewerbungen")
   Set doc = view.GetFirstDocument

'Dokumente zählen   
   For i = 0 To view.AllEntries.Count
      If doc Is Nothing Then Exit For
      If Right(doc.Jahr(0),4) = Jahr Then   i2 = i2 + 1
      Set doc = view.GetNextDocument(doc)
   Next
   
'lfd. Nummer setzen
   Set doc = uidoc.Document
   doc.lfdNr = i2 + 1   
End Sub</sub>


Gruß
Demian

[Axel]

Das funktioniert aber auch nur solange, wie die DB nur von einem einzigen Benutzer verwendet wird.

Ansonsten gilt die Aussage von Klauss

Und was noch dazu kommt, der Benutzer muss das Feld auch wirklich verlassen.

Was machst du, wenn der User speichert und der Cursor steht noch in diesem Feld. Das Exiting - Event eines Feldes wird nicht immer zuverlässig ausgeführt.



Axel

[DerAndre]

Unter Beachtung aller Sicherheitshinweise hätte ich auch noch einen Vorschlag:

Ein Numberingdocument erstellen
Im Querysave-Event auf das Document Zugreifen
Nummer Hochzählen
Nummer Reinschreiben ( in das Numberingdocument und in das aktuelle Zählerfeld )
Numberingdocument speichern

Das sollte einigermassen brauchbar Funktionieren, tut es bei uns zumindest...

[klaussal]

Und auch hier gilt:

Das funktioniert aber auch nur solange, wie die DB nur von einem einzigen Benutzer verwendet wird.

[smoki]

Du kannst auch eine Pseudonummer vergeben bsp -1.

Und nach dem Speichern einen Agenten auf dem Server starten, der alle Dokumente mit -1 durchnummerieren soll (auf basis eines Profildokuments, dass den aktuellen Zähler enthält).

Normalerweise kann niemals ein Agent zweimal gleichzeitig auf dem Server laufen. (Es gibt aber einen Notes.ini Eintrag, der dieses Verhalten verändert!)

Wenn du über mehrere Repliken hinweg arbeitest, muss beachtet werden, dass der Agent nur auf einem Server ausgeführt wird.

Dann bleibt die Laufnummer so lange -1 bis sie auf dem Server der Nummeriert einschlägt. Dort sollte ein periodischer Agent laufen, der den Hochzählagenten startet.

Man kann sich noch mehr aus denken, dann wird es aber immer schwieriger

Ggf. gibt es bei diesen Verfahren Replizierkonflikte aber die treten trotz heftiger Nutzung bei uns fast nie auf;)

Gruss
Christian

[Demian]

Hallo,

zu Axel:

Das funktioniert aber auch nur solange, wie die DB nur von einem einzigen Benutzer verwendet wird.

Naja gut, wenn 2 Leute gleichzeitig die Maske speichern, würde es mit dem Code zu Problemen kommen, aber sonst doch nicht, oder?

Und was noch dazu kommt, der Benutzer muss das Feld auch wirklich verlassen.

Was machst du, wenn der User speichert und der Cursor steht noch in diesem Feld. Das Exiting - Event eines Feldes wird nicht immer zuverlässig ausgeführt.

Für den Fall frage ich im Querysave der Maske immer ab, ob alle Felder ausgefüllt sind, wenn nicht wird der Speichervorgang mit entsprechendem Hinweis abgebrochen

Gruß
Demian

[Axel]

zu Axel:

Das funktioniert aber auch nur solange, wie die DB nur von einem einzigen Benutzer verwendet wird.

Naja gut, wenn 2 Leute gleichzeitig die Maske speichern, würde es mit dem Code zu Problemen kommen, aber sonst doch nicht, oder?

Hab ich ja geschrieben. So lange nur ein User zugreift wird es gut gehen.

zu Axel:

Und was noch dazu kommt, der Benutzer muss das Feld auch wirklich verlassen.

Was machst du, wenn der User speichert und der Cursor steht noch in diesem Feld. Das Exiting - Event eines Feldes wird nicht immer zuverlässig ausgeführt.

Für den Fall frage ich im Querysave der Maske immer ab, ob alle Felder ausgefüllt sind, wenn nicht wird der Speichervorgang mit entsprechendem Hinweis abgebrochen

Warum machst du denn dann nicht gleich alles im Querysave-Event?

Axel
 

[koehlerbv]

Abgesehen davon macht der Einsatz im Exiting-Event die ganze nochmals unsicherer: User A legt Dokument an, verlässt irgendwann das betreffende Feld, trägt hier und da noch was ein - dann klingelt das Telefon. Währenddessen zieht User die Erstellung eines neuen Dokuments flott durch und speichert. Da davon das Dokument von User A "nichts weiss", haben jetzt beide Doks die gleiche Nummer, wenn User A speichert.

Im geposteten Code finde ich übrigens keine Sperre dafür, dass bei einem Verlassen des Dokuments bei erneuter Editierung nicht auch wieder eine neue Nummer vergeben wird.

Die Diskussion um fortlaufende Nummern, die wir hier schon so oft geführt haben, sollten wir aber nicht erneut aufkochen. Wer nach "fortlaufend" oder "sequentiell" sucht, wird entdecken, dass wirklich schon alles hierzu gesagt wurde.

Bernhard

[klaussal]

Die Diskussion um fortlaufende Nummern, die wir hier schon so oft geführt haben, sollten wir aber nicht erneut aufkochen. Wer nach "fortlaufend" oder "sequentiell" sucht, wird entdecken, dass wirklich schon alles hierzu gesagt wurde.

Aber anscheinend haben das noch nicht alle kapiert 

[Demian]

Moin Bernhard,

habe in dem "Jahres-Feld" unter Eingabe aktiviert die Formel "@if(@isnewdoc)".

Werde aber wohl den Vorschlag von Axel umsetzen und alles im Querysave machen. Dann würde es auch bei deinem Beispiel nicht zu Problemen kommen.

Gruß
Demian

[aks]

Danke für die vielen Beiträge. Das Thema fortlaufende Nummer ist ja wohl wirklich etwas schwieriger :-(

[koehlerbv]

... alles im Querysave machen. Dann würde es auch bei deinem Beispiel nicht zu Problemen kommen.

Benutze die Forumssuche - so findest Du die anderen Beispiele, die zeigen, warum das eine so unsichere Kiste ist. Wie gesagt - es ist alles schon zigmal erläutert worden.

Bernhard

[Demian]

habe den Beitrag nicht eröffnet. HAbe nur geschrieben, wie ich es gelöst habe. Von daher bin ich mit dem Zusatz von Axel völlig zufrieden 

[koehlerbv]

Von daher bin ich mit dem Zusatz von Axel völlig zufrieden 

Na, dann wünsche ich in der Zukunft viel Spass. Auch mit der Forumssuche wirst Du vermutlich folgendes Beispiel nicht finden, weil es spezifisch an den Code gebunden ist, mit dem Du zufrieden bist:
Da Du stur die Dokumente in der Ansicht zählst, bist Du (eher die anderen - Du bist ja zufrieden) unter anderem folgenden Gefahren ausgesetzt:
- Selten: Wegen der Performance-Belastung steigt mit zunehmender Dokumentanzahl das Risiko, dass User A gerade speichert (und Deinen Code ausführt), während User B diesen Prozess erst startet. Wenn dann nicht schnell genug der View-Index wieer aufgebaut ist - bumm.
- Sicher: Irgendwann löscht mal jemand mindestens ein Dokument, welches nicht gerade zufällig das letzte in der Ansicht ist. Da gibt's dann eine doppelte Nummer. Wenn jemand vielleicht sogar mehrere Dokumente löscht ... daran mag ich gar nicht denken 

Bernhard

[Demian]

Der Azubi, der diese Dokumente erstellt, ist per ACL schon vom Löschen von Doks ausgeschlossen. Und er/sie ist der/die einzige, der diese Doks erstellt.

Die anderen können zwar in der Datenbank Doks löschen, aber für diverse Ansichten, unter anderem auch für diese, sind im Datenbankereignis Querydocumentdelete Blockaden drin.

[smoki]

Ich finde mein oben genannter Ansatz mit Server-Agent für die Nummerierung ist doch ein ganz gangbarer Weg... nur nicht sehr trivial...

Kurz nochmal:

Laufende Nummer 0 oder -1 geben und speichern.
Mit RunOnServer einen Agent für die Nummerierung starten.
Ein Agent mit dem selben Namen wird nicht doppelt im Agent-Manager ausgeführt, dass stellt Doppeltnummerierungen sicher.

Mit Clustern ode Replikation muss man natürlich noch paar Dinge mehr beachten....

Gruss
Chris