lahme Ansichten

[Lloyd]

Hallo,
wir haben hier eine Datenbank wo wir die Arbeitszeiten unserer Mitarbeiter erfassen. Der Mitarbeiter hat 3 Buttons "Kommen" - "Pause/Fortsetzen"- "Ende".
Soweit nichts ungewöhnliches.

Beim Starten der Datenbank wird eine Maske geöffnet in der eine eingebettete Ansicht angezeigt wird, die die aktuellen Tagesbuchungsdokumente enthält. Bis die sich aufgebaut hat, dauert es häufig (nicht immer) sehr lange. Die Datenbank ist noch nicht sonderlich groß (55.000 Dokumente und 1.4 GB Plattenplatz). Aber dennoch wird die Datenbank beim öffnen und öfters auch beim betätigen der Buttons (hier werden auch diverse versteckte Ansichte abgefragt) sehr sehr sehr langsam. Das macht sie nicht jedes mal, aber zu häufig.

Die Datenbank ist geclustert (selbe Lokation). Was mir aufgefallen ist, dass der Indexer Task auf dem Server sehr häufig auf der Datenbank läuft, zumindest gefühlsmäßig. Die Ansicht beim Öffnen ist auch nichts besonderes, hier werden vom angemeldeten Benutzer die aktuellen Tagesdokumente eingeblendet.

Der Select lautet:

SELECT ((FORM = "zeit_childdok") | (FORM = "zeit_childdok_abwesendhalb") & (@Name([Abbreviate];stammp_mitarbeiter) = @Name([Abbreviate];@UserName)) & (@Date(zeit_datum) = @Today)

Hat jemand ein paar Tuningtipps für mich?

[koehlerbv]

Das ist so ziemlich das tötlichste, was man machen kann: @Today

Bei jedem Öffnen der Ansicht wird diese durch die enthaltene Zeitkomponente in der Formel komplett neu aufgebaut. 55.000 Dokumente sind dann auf einmal sehr viel. Ausserdem dürfte die Anzahl der dauernd neuen und geänderten Dokumente pro Zeiteinheit sehr hoch zu sein.

Nimmt man das @Today heraus, funktioniert @UserName nicht mehr - die Katze beisst sich in den Schwanz. Vulgo: Das Gesamtkonstrukt ist falsch.

Bernhard

[Glombi]

@Username in der SELECT Formel bedeutet, dass es eine private Ansicht ist, oder?. Sonst funktioniert das nicht wie gewünscht.

@Today in SELECT oder Ansichtsspalten ist ein Performancekiller. Da gibt's hier im Forum einiges zu.

Andreas

[koehlerbv]

Wir haben aus gutem Grunde in einem Zeiterfassungssystem jedem User seine eigene DB (ohne @Todays) spendiert, die über das Verwaltungssystem erzeugt und verwaltet und zusammengegrabbelt werden - dort dann natürlich auch ohne jegliche @Todays).
Aus purem Übermut haben wir diesen (sehr gut funktionierenden) Aufwand natürlich nicht betrieben.

Bernhard

[Lloyd]

Da ist wohl das Problem. Es wurde an ein paar Stellen mit @Today in Ansichten gearbeitet um den Zeitsaldo beim öffnen oder aktualisieren auf die Minute genau zu errechnen.

Tja, dann muss ich mich wohl nochmal mit der Thematik @Today intensiv auseinandersetzen.

Vielen Dank schonmal für die Hinweise.

[domino23]

Ich habe damals bei meiner Zeiterfassung beim Speichern, Buchen etc. alle relevanten Zeitstempel (Datum, Uhrzeit) in versteckte Felder geschrieben und in den (eingebetteten) Ansichten dann mit kategorisierten Spalten gearbeitet.
Auch in der Maske, in der die eingebettete Ansicht angezeigt wurde, gabs diverse versteckte Felder die unterschiedliche Trigger für Berechnungen hatten (auf Knopfdruck, beim Verlassen eines Feldes, beim Speichern, beim Schliessen etc.).

@Today kann(!) man umgehen, indem man irgendwo in der DB immer den aktuellen Tag speichert und die ganzen Datums- und Zeitstempel dann mit Formelsprache aufsplittet und verwurstet. Da würde ich auf Profildokumente verzichten. Die sind zwar super geeignet für solche Sachen, aber die bleiben gerne mal im Cache und aktualisieren sich nicht immer wie/wann man will. Ich persönlich würde auch von privaten Ansichten und Ordnern absehen....

Für das Design habe ich natürlich kein goldenes Abzeichen in mein Hausaufgabenheft bekommen, ich bin aber gegen die gleiche Falle gelaufen wie Du. Historisch gewachsen quasi 


Max

[v_haderer]

Versuch mal eine in einer Maske eingebettete SingleCategory-Ansicht
-verstecktes Datumsfeld beim Öffnen mit Tagesdatum befüllen (Feld DummyDat)
-Kategorie 1te Spalte nach "Username+DummyDat"

lg
V

[thkn777]

Hm, wie wär's mit:
- embedded view, die nach stammp_mitarbeiter kategorisiert ist und nur eine (single) category anzeigt, nämlich die des aktuellen Nutzers?
- alternativ @SetViewInfo( [SETVIEWFILTER]... benutzen

Und:
- Beim Speichern der Zeitbuchungsdokumente gleich ein "isToday" Item mitführen. Das Berechnen in der Maske gegen @Today ist performancetechnisch ok. Zusätzlich baust Du einen Pflege-Agenten, der früh um 00:01 Uhr in allen Dokumenten, die nicht @Date(zeit_datum) = @Today haben, "isToday" auf falsch setzen

In Deiner Ansicht sehen die Nutzer dann nur jeweils ihre Dokumente und mit

SELECT ((FORM = "zeit_childdok") | (FORM = "zeit_childdok_abwesendhalb") & isToday

wird das Select auch übersichtlicher und der Indexer freut sich. Geht gut, solange keine Leser- und Autorenfelder auf den Dokumenten sind.

Falls mal was schiefgeht und der Pflegeagent nicht gelaufen ist in der Nacht, kann man den auch einfach mal tagsüber laufen lassen