Anzahl Tage von einem bestimmten Zeitraum bis heute in Ansicht anzeigen

[Schorschi353]

Hey Leutz,

ich möchte in einer Ansicht die Anzahl der Tage anzeigen lassen, die vergangen sind, seid ein Dokument erstellt wurde.
Man soll also sehen, wieviele Tage es her ist, dass das Dokument erstellt wurde.

Ist sowas möglich? Wenn ja wie? 

In der Suche hab ich dazu leider nix gefunden..

Danke euch schonmal vielmals!!

Marius

[koehlerbv]

Ich bin zwar nicht "Leutz", aber: @Today und @Created sollten in den DesignerHelp studiert werden. Weiters: Ansichten mit Bezug auf das aktuelle Datum können bei entsprechender Dokumentenzahl ein Performacekiller allererster Güte werden!

Bernhard

[Schorschi353]

Danke Bernhard für deine schnelle Antwort!

Ich habs jetzt so gelöst:

@Abs((@Today - @Created) / 86400)

Natürlich ist mir bewusst, dass die Performance leiden kann, wenn die Dokumentenanzahl zunimmt, das muss ich dann einfach im Auge behalten und ggf die Formel in der Ansicht wieder rausnehmen.

Sankedön! 

Marius

[koehlerbv]

Hallo Marius,

erwartest Du Einträge aus der Zukunft? Steht Euer Domino mit der Enterprise in Verbindung?  Das @Abs macht ja sonst eher weniger Sinn 

Bernhard

[jo@chim]

Hallo MariusZ...
... so schnell kannst Du gar nicht schauen, wie Deine Performance im Produktivbetrieb in den Keller gehen wird. Und dann gibts eins aufs Auge (von den Anwendern) 

Um das Problem zu umgehen, habe ich mir einen Agenten gebastelt, der mir jede Nacht in den Spalten- und Selektions-Formeln aller Ansichten die Variable "_varAct" sucht und diese mit dem aktuellen Datumswert belegt (Code siehe unten - Importiere das LS einfach in einen zeitgesteuerten Agenten, Ziel alle Dokumente, den Du täglich ablaufen lassen kannst).

Wenn Du dann in einer Spalte das Alter eines Dokuments in Tagen anzeigen willst, schreibe folgende Spaltenformel:

Code

_varAct:=@ToTime("24.04.2008");
@ToNumber(_varAct-@created)/86400

Hier @Abs zu nehmen ist natürlich @absoluter Unsinn, wie Bernhard schon richtig bemerkt hat 

Die erste Zeile mit der Variable bitte genau so in die Spalten- oder Selektionsformel schreiben!

Hier also der Code für den Agenten:

Code

Option Public
Sub Initialize
	Dim session As New NotesSession
	Dim db As NotesDatabase
	
	'Name der Variablen für den Datumswert in den Views
	varActStr$="_varAct"
	
	datStrStart%=Len(varActStr$)+12
	k=0
	m=0
	
	Set db = session.CurrentDatabase
	views = db.Views
	On Error Resume Next
	Forall v In views		
		Print "Lese " & v.Name & " -  Selection Formula"
		org_formula$=v.SelectionFormula
		If Left(org_formula$, Len(varActStr$)) = varActStr$ Then
			k=k+1
			Print "Aktualisiere " & v.Name & " -  Selection Formula"			
			org_formula$=v.SelectionFormula
			org_dat$= Mid(org_formula$,datStrStart%,10)
			new_dat$=Format(Now(),"dd.mm.yyyy")
			new_formula$=Replace(org_formula$,org_dat$,new_dat$)
			v.SelectionFormula=new_formula$			
		End If
		
		i=0
		Forall vc In v.Columns
			i=i+1
			
			Print "Lese " & v.Name & " -  Spalte Nr. " & Cstr(i) 
			org_formula$=vc.Formula
			
			If Left(org_formula$, Len(varActStr$)) = varActStr$ Then
				m=m+1
				Print "Aktualisiere " & v.Name & " -  Spalte Nr. " & Cstr(i) 
				org_formula$=vc.Formula
				org_dat$= Mid(org_formula$,datStrStart%,10)
				new_dat$=Format(Now(),"dd.mm.yyyy")
				new_formula$=Replace(org_formula$,org_dat$,new_dat$)
				vc.Formula=new_formula$				
			End If
			
		End Forall
	End Forall
	
	Print Cstr(k) & " Selection Formulas, " & Cstr(m) & " Column Formulas aktualisiert"
End Sub

Viel Glück 

[koehlerbv]

Joachim,

Deine Lösung kann aber auch tierisch nach hinten losgehen: Wenn Replizierkonflikte nicht gemischt werden (und 7.0.3 hat da doch ein tierisches Problem, IIRC) oder Leute in Takatukaland sitzen und diese Datenbank replizieren müssen und ...

Wenn Du eine DB hast, in der 5000 Dokumente in 5 Jahren noch nicht erreicht sind, bekommst Du hingegen auch keine Performanceprobleme, die irgendwen aufregen würden.

Man muss also die Vorgehensweisen sorgfältig abwägen ...

Bernhard

[Schorschi353]

Hey Bernhard, Hey Joachim,

danke zunächst für eure schnellen Antworten!

Aber so unsinnig ist das @Abs nicht, guckst du beide hier:

                                http://atnotes.de/index.php?topic=10466.0

Also momentan wird die DB nur hier am Standort genutzt, Timbuktuianer sind also erstmal ausgeschlossen. 

Wir haben Version 7.0.2 und die Dokumentenanzahl wird 5.000 Stück wohl nicht erreichen..
Ich werde den Agent gleich mal testen..

Marius

[jo@chim]

Wenn Replizierkonflikte nicht gemischt werden (und 7.0.3 hat da doch ein tierisches Problem, IIRC)

Sprich! Wo können bei der Replikation der Gestaltungselemente Probleme auftreten?

btw: 5.000 Dokumente scheint mir etwas euphemistisch... durch die ständigen Aktualisierungen bei @today-Spaltenformeln, die die Arbeit im kompletten Client alle paar Minuten für ein oder zwei Sekunden blockieren, kannste den Anwendern das Leben auch bei kleineren DB's ganz schön zur Hölle machen  (1.000 Doks haben hier vollkommen ausgereicht)

[m3]

Wenn Replizierkonflikte nicht gemischt werden (und 7.0.3 hat da doch ein tierisches Problem, IIRC)

Sprich! Wo können bei der Replikation der Gestaltungselemente Probleme auftreten?

Replikation der Daten, nicht des Designs. Ein kleiner aber feiner Unterschied.

Jedes mal, wenn zwei Personen einen Datensatz gleichzeitig bearbeiten.

[botschi]

Das hab ich jetzt aber auch nicht geschnallt 

Wenn zwei Personen zeitgleich Daten ändern und die Konflikte nicht gemischt werden, gibt es doch immer "Probleme".
Was hat das denn jetzt mit Achims Agenten zu tun? Denn müsste ja schon ein Entwickler zeitgleich mit dem Agenten die Ansicht ändern?
Davon mal abgesehen, dass ich das auch nicht so machen würde... Ich lasse ungerne jede Nacht Agenten laufen die Doks (in diesem Fall die Ansichten) bearbeiten, nur damit eine View stimmt.

Matthias

[koehlerbv]

Ich habe schlicht übersehen, dass Joachim die Ansichten selbst ändert - mea culpa. Das hat mit möglichen Replizierkonflikten natürlich nichts mehr zu tun.

Bernhard

[jo@chim]

Ich habe schlicht übersehen

Uffffff... *tiefausatmen*... ich hatte jetzt tatsächlich die Befürchtung, dass es, wenn die Agents auf ihren jeweiligen Servern die Spalten-/Selektions-Formeln ändern, irgendwelche schrägen(Replikations-) Effekte gibt...
 

Aber @botschi:

Davon mal abgesehen, dass ich das auch nicht so machen würde... Ich lasse ungerne jede Nacht Agenten laufen die Doks (in diesem Fall die Ansichten) bearbeiten, nur damit eine View stimmt.

Wie würdest Du es denn machen? Die einzige Alternative zur @today-Misere, die mir einfällt, wäre statt der Views die Docs anzufassen und jede Nacht eine entsprechende Markierung reinzuschreiben, die Vergleiche zum aktuellen Datum ermöglicht... aber besser 10 Ansichten als 10.000 Dokumente. Odddrrr?!   

[m3]

Ich habe schlicht übersehen

Uffffff... *tiefausatmen*... ich hatte jetzt tatsächlich die Befürchtung, dass es, wenn die Agents auf ihren jeweiligen Servern die Spalten-/Selektions-Formeln ändern, irgendwelche schrägen(Replikations-) Effekte gibt...
 

Ok, das hab ich auch übersehen.
ABär: Wenn die Datenbanken replizieren und der Agent auf jedem Server läuft, hat man erst recht wieder einen Palawatsch beinander - und sogar noch schlimmer, weil nicht die Dokumente, sondern die View-Nodes Konflikte werfern. Brrrrr, das will ich mir gar nicht vorstellen, Replizierkonflikte bei Design-Elementen.

Oder lieg ich da falsch liebe Gurus?

[koehlerbv]

Nun, wer würde solch einen Agenten auf allen Servern laufen lassen? Und: Designelemente können in der Regel keine Replizierkonflikte bilden - da ist der Repliziermechanismus davor.

Bernhard

[m3]

Was passiert dann aber, wenn so ein Agent auf allen Server laufen würde? Ich denke schon, dass es Probleme geben würde. Aber welche?

[koehlerbv]

Naja, nachdem der Agent überall gelaufen ist und wieder alle Server miteinander repliziert haben, wirst Dui feststellen können, wann der Agent zuletzt gelaufen ist und auf welchem Server. Dann weisst Du, welcher Server am ausgelastetsten ist (oder wessen Uhr nachgeht). 

Bernhard

[m3]

*gggg*
Das ist ja fast langweilig. 

[jo@chim]

(oder wessen Uhr nachgeht). 

Oder vorgeht? In Amiland zum Speispiel? 

Konnte ich aber bisher nicht verifizieren. Vielleicht weil der Agent auf der Replik dort nicht läuft, oder warum?

Diese Dimension des Problems hatte ich bisher überhaupt nicht beachtet... heidernei! Na, das wird ja ein spannender Montag...

[koehlerbv]

Also im Amiland geht die Uhr "nach", nicht vor. Ausserdem ist's eh wurscht, da der Agent sicherlich mit mitteleuropäischer Zeitzone eingestellt wurde. Und dann startet der Agent im Amiland "gleichzeitig" mit dem in Europa.

Bernhard

[LN4ever]

Das Problem mit Zeitvergleichsansichten kann man entschärfen, indem man in den Ansichtseigenschaften einstellt, daß der Server diese Ansicht max. alle x Stunden aktualisiert. Das hat den Preis, daß das Öffnen dieser Ansicht durch einen User langsam ist, manchmal sehr langsam.

Aber wenn die Tagesdifferenz von entscheidender und geschäftskritischer Bedeutung ist, dann werden die Benutzer damit einverstanden sein oder sich daran gewöhnen oder die Datenbank meiden oder den Programmierer erschlagen.

Von Lösungen wie der vorgeschlagenen, täglich die Selektionsformel zu ändern, halte ich gar nichts. Nicht wegen der Zeitzonen, sondern, weil die Ansicht in einer über einen gewissen Zeitraum nicht replizierten lokalen Replik damit falsche Angaben liefert.

Und wenn man das dann vermeiden will, dann muß man den Anwendern Entwicklerrecht geben und diesen Agenten lokal periodisch im Hintergrund laufen lassen - und da sind wir bei der Einstellung, daß der Agent auf jedem Server ausgeführt wird. Das ist von der Theorie her nicht gar zu schlimm, weil Designelemenrte keine Replikationskonflikte erzeugen, aber es wird schlimm, wenn nacheinander der Japaner, der Amerikaner und der Europäer mit jeweils frisch modifizierter Ansicht replizieren, weil bei jedem die Zeitdifferenz in seiner jeweils verwendeten Zeitzone errechnet wird, und damit die in der Ansicht ausgewiesenen Tagesdifferenzen mehrfach am Tag hin- und herspringen können und insofern auch nicht stimmen können.

Man kann mit einem periodischen Agenten schwellwertüberschreitenden Dokumenten ein ansichtsauswertbares Flag mitgeben. Damit erhöht man allerdings das Repliziervolumen oft erheblich und läuft Gefahr, ziemlich unnötige Replizierkonflikte zu erzeugen.

Resumée: wenn es nicht wirklich sein muß, dann laß es sein.

Gruß

Norbert