Das Öffnen eines neuen Dokuments dauert sehr laaaaaaaaaaaaange

[Bruce Willis]

Hallo,

man öffnet eine Datenbank, nach eine Weile klickt auf den Button
@Command([Compose];@DbName;"MeineTolleMaske")
und wartet etwa 15 Sekunden, bis ein neues Dokument erscheint.

Wenn man das Dokument ohne zu speichern schließt und den Button nochmals anklickt, dann dauert das Öffnen nur etwa 2 Sekunden.

Ich habe schon die Felder mit @DbColumn und @DbLookup überprüft.

Woran kann es noch liegen?

Gruß
Leo

[Driri]

Werden viele Teilmasken verwendet ? Da gibt es so einen netten Bug, daß wenn in den Events der Teilmasken keine Scripte hinterlegt sind, die Performance beim Aufbau der Teilmasken in den Keller geht.

Es reicht dann aus, z.b. im Initialize der Teilmasken irgendein Dummy-Statement einzubauen (z.B. Print oder Dim).

[ata]

... ein weiterer Grund können kleine Hintergrundgrafiken sein, die sich aufrastern...

Vermutlich aber verwendest du mehrere Teilmasken ohne Script, wie bereits genannt. Dann eben ein LS Code wie

Private Const dummyPerformance = True

in den Declarations der Teilmasken einbauen.

Toni

[Bruce Willis]

Vielen Dank für die Vorschläge.
Leider sind in der Maske keine Teilmasken integriert.

Was noch könnte das Problem verursachen?

Gruß
Leo

[ata]

... was ist mit Hintergrundgrafiken?

Hast du DBLookup's oder DBColumns in großer Anzahl drin?
Gibt es irgendeinen Code, der beim Laden ausgeführt wird?

Toni

[Bruce Willis]

Sorry, Toni.
Ich hab vergessen zu schreiben:

... was ist mit Hintergrundgrafiken?

Keine.
Nur ein kleines Firmen-Logo ganz oben.

Hast du DBLookup's oder DBColumns in großer Anzahl drin?

Etwa 30 Felder...
Aber etwa 25 davon sind zur Anzeige und ich habe sie mit @IsNewDoc deaktiviert.
Hat leider nichts gebracht.
Die waren allerdings sowieso "NoCache" und konnten daher den Unterschied 15 vs. 2 Sek nicht verursachen.

Gibt es irgendeinen Code, der beim Laden ausgeführt wird?

Nur ein paar Zeilen:

Code

		Dim s As New NotesSession	
		hostname= Environ("COMPUTERNAME")
		Username= Environ("USERNAME")
		Call s.SetEnvironmentVar("Benutzer",hostname + " - " + Username)

und das:

Code

Use "WindowsClipboardClass"

Gruß
Leo

[ata]

Hallo Leo,

... als Tip zur Recherche,

Nimm verschiedene Elemente aus der Maske, also Teilmasken, Aktionen, berechnete Felder, und vergleiche die Öffnungszeiten der Masken. So kannst du eingrenzen, wo die Performance flöten geht. Der Debugger kann auch behilflich sein...

Toni

[DerAndre]

Wie sieht es mit Embedded Views aus?
Wenn diese in andere Datenbanken zeigen geht die Performance auch in die Knie.

[Lloyd]

Hi,
diese Verhalten hab ich auch mal gehabt. Bei mir lag es an folgendem (unter anderem Unwissenheit)  

Ich erstelle ein neues Dokument und habe nach dem anklicken des Button zunächst überprüft ob ein Lizenzcode hinterlegt ist. Damals war es möglich in einer Ansicht mehrere Lizenzdokumente abzulegen (z.B. für 2010,2011,...). Unglücklicherweise habe ich damals den User abgefragt um über die NotesRegistration einige Infos abzuziehen. Das wurde für jedes Dokument in der Ansicht gemacht, bis ein Lizenzcode gefunden wurde der passt. Über Set doc = view.getNextDocument(doc) bin ich immer zum nächsten Dokument gewechselt.

Der Zweite Aufruf war immer sehr schnell, lediglich der erste war wie bei dir sehr langsam. War in der Ansicht kein Dokument oder lediglich ein einziges, war alles schnell.

Geschickter war es nur ein einziges Dokument zu verwenden, wo ggbfs. mehrere Lizenzcodes hinterlegt werden können.

[Bruce Willis]

... als Tip zur Recherche,

Nimm verschiedene Elemente aus der Maske, also Teilmasken, Aktionen, berechnete Felder, und vergleiche die Öffnungszeiten der Masken. So kannst du eingrenzen, wo die Performance flöten geht. Der Debugger kann auch behilflich sein...

SUPER Tip, Toni!
Vielen Dank!

Ich danke auch allen anderen Beteiligten!

Der ganze Sch* lag an einem einzigen versteckten Feld mit @DbLookup und @Today

Code

@DbLookup ( "" : "NoCache" ; "" : "" ; "DCalMail" ; @Date (@Today)  ; "DName"; [FailSilent] ) 

It's strange, warum die folgenden neuen Dokumente bei "NoCache" so schnell geöffnet wurden...

Gruß
Leo

[koehlerbv]

It's strange, warum die folgenden neuen Dokumente bei "NoCache" so schnell geöffnet wurden...

Leo, sooo doof ist dbLookup nun auch mit NoCache nicht. Man vergleiche die Reaktionszeiten mit "NoCache" und mit "ReCache".

Ich denke, viel interessanter wird die verwendete Ansicht sein - insbesondere, da hier auf @Today abgefragt wird, schwant mit da was. Ich denke, dort wird der "Hund begraben" sein. Armer Hund ... 

Bernhard

[ata]

Hallole

... das sieht ganz danach aus - da wird der Index das Problem sein...

Toni

[Bruce Willis]

Hi,

Danke fürs Feedback!

Ich hab jetzt die fragliche Funktion etwas anders realisiert.
Aber für die Zukunft:

Die Ansicht sieht so aus:

Code

SELECT (
@IsAvailable(CalendarDateTime)   &
@Date(CalendarDateTime) = @Today   &
Teamauswahl = TeamDoD &
@Contains (DoDName; "Feiertag") != 1
 )

Der Index ist hier im Screenshot angezeigt.

Wenn ich auf "Automatisch, max alle 4 Stunden" einstelle, werden die Dokumente nicht gefunden, die in den letzten 4 Stunden ersellt sind.

1. Stimmt's?

2. Was hätte man verbessern können?
(die Ansicht muss auch in den lokalen Repliken funktionieren)

Gruß
Leo

[ascabg]

Hi,

Das ist aber der Volltextindex und waere interessant bei einem FTSearch.

Fuer einen Lookup ist, soweit ich noch weiss, der Ansichtsindex ausschlaggebend. Und da mit @Today gearbeitet wird, ...


Andreas

[m3]

Du willst keine View-Selection mit @Today ...

http://www-10.lotus.com/ldd/bpmpblog.nsf/dx/today-in-a-view
http://www-10.lotus.com/ldd/bpmpblog.nsf/dx/Indexing-options-and-Today

Bitte glaube Andre Guirard. Wenn es der nicht weiß, ...

[Bruce Willis]

Das ist aber der Volltextindex ...
Fuer einen Lookup ist, soweit ich noch weiss, der Ansichtsindex ausschlaggebend.

Hallo Andreas,

Danke.
Und wo finde ich Einstellungen für die Ansichtsindex  ?

Gruß
Leo

[koehlerbv]

Leo, Du warst da in Post #12 schon richtig - das sind die Ansichtsindex-Parameter und nicht die vom FTI.

Dein "Problemkind" bleibt aber das @Today ...

Bernhard