Hi, ich fang mal an...
Generell:
Ich habe für mich entschieden, Dim und Set immer zu trennen.
Das Dim kommt immer in Declarations und Set dann wo man/frau es braucht.

Was oft Sinn macht (muss halt von DB zu DB geprüft werden):
Häufig verwendete Objekte wie NotesSession und NotesDatabase können in einer Script Library dimensioniert und dort im Initialize gesetzt werden.
Als Name nehme ich dann sowas wie
dim GLOBALS_session as NotesSession
dim GLOBALS_db as NotesDatabase

wobei "GLOBALS" den Name (zumindest eindeutiges Präfix) der Library ist. Dann weiss man später im Script immer, wo die Dinger herkommen.

In Masken macht es Sinn, unter (Globals) folgendes zu deklarieren:
dim uidoc as NotesUIDocument
dim doc as NotesDocument

und das dann im Postopen/Queryopen zu setzen.

Tip:
Alle Objekte, die in Script Libraries unter (Declarations) deklariert werden und die NUR INNERHALB der Library verwendet werden, als Private deklarieren. Sonst kann es Stress geben, wenn man nachträglich eine Library bspw. in eine Maske einbindet und gleiche Namen verwendet.

Bei der Verwendung von UI-Klassen ist bzgl. Script Libraries folgendes anzumerken:
Alle Objekte, Functions etc. die UI-Objekte verwenden, behandle ich in einer eigenen Script Library. Es gibt nämlich die Einschränkung, dass diese Libaries nicht in servergestützten Agenten verwendet werden können (sonst kommt Error Use lsx oder sowas).

to be continued...

Andreas

Hi,
Du machst aber überall ein
Use "Name der Script Library"
wenn Du "MAIN_dbAddress" brauchst, oder?

Wegen der UI-Objekte: Ja, das mit Variant geht (macht Lotus auch im Mail). Finde ich persönlich aber nicht so schön.

Andreas

... Variant verwende ich, wenn ich rekompilieren muß...

... und warum?

Ist vielleicht schon zu spät und eknori hat mich aus der Fassung gebracht, aber ich komm nicht drauf. Brauche vielleicht auch Urlaub

Andreas

ebenfalls sorry - das Wetter war zu gut  

ata: Ja, ich habe überall den use "blablabla" drin. In den Globals ist dann auch die variable - nur isse leider wieder nicht gesetzt.
das bedeutet, dass ich sie jedesmal neu "initialisieren" muss - und das wollte ich grad vermeiden  

Aber weiter oben (hm, nach dem Posting dann wohl weiter unten) war auch die Antwort auf die Frage: Es gibt einfach keine datenbankglobalen Variablen! Sehr, sehr schade..

CPO

Profildokumente finde ich auch nicht so toll (obwohl sie Performance-mässig sicher sehr gut sind). Unter 4 hatte ich mal gewaltige Probleme im Kontext von Replikation und danach waren die Dinger für mich gestorben. Weiß nicht ob das Problem noch fortbesteht.

Ich arbeite für globale Daten immer mit einem einfachen Dokument mit einer Maske config und einer view config. In dieser view ist immer genau ein Dokument (es ist somit quasi wie ein Singleton-Objekt in OO mit state aber ohne behaviour).
Man hat dann direkt auch eine einfache/übersichtliche Möglichkeit zur Parametrisierung von Anwendungs-globalen properties für Kunden/Endanwender.  

Bei ini-Variablen sollte man sich genau Gedanken machen, wann diese eventuell gelöscht werden. Viele Leute vergessen das. Ansonsten ist dies zwar völlig old-school und error-prone, aber manchmal eben auch ganz nützlich.

Yep, alles richtig, aber entscheidend ist die Aussage von ata: Keine DB-globalen Objekt-Variablen (Danke, ata)
Das Problem ist doch einfach die Performance: Wenn ich eine verlinkte DB immer wieder btrauche, muss ich sie immer wieder setzten und LS braucht immer wieder tierisch lange...
OK - hab' ich aber jetzt begriffen: geht nich  

Profildokumente nutze ich eigentlich ständig. Seitdem wir sie nicht mehr für Sachen nutzen, die sich ständig ändern (Zähler...) gibt's auch keine Probleme mehr in Clustern...

Ini-Einträge haben seit den Profiles bei mir deutlich abgenommen. Nehme ich eigentlich nur noch, wenn ich wirklich DB-übergreifend und userspezifisch irgendwas speichern will. Oder wenn halt mal ganz schnell ein Text von Script an @@ übergeben werden muss  

CPO