Falls ich mich recht erinnere, gibt @dbName für den ersten Wert der Ergebnisliste nie etwas zurück. (Kann mich irren).
Hiess diese seit Notes4 in der Webentwicklung sehr gebräuchliche Formel zur Generierung von nicht-hart-kodierten URLs nicht:
(das -1 ist wichtig). Das funktioniert auch. Eben ausprobiert. Guck besser noch mal bei den Formeln nach, die schon vorher in der Datenbank funktioniert haben. Vielleicht hast du einfach das - übersehen.
Oder noch besser:
@ReplaceSubstring(@Subset(@dbName;-1); "\\";"/");
Danke für die Antort. Klar, um den Server unabhängig den Db-Pfad zu erhalten, kann man deinen Code verwenden.
Gemäss Help sollte @DbName aber wirklich zwei Werte zurückgeben.
Syntax
@DbName
Return value
server ; path
Text list with two elements
gibt den Pfad zurück
sollte den Servernamen zurückgeben, und genau das funktioniert nicht mehr.
Als Workaround verwende ich jetzt
@ReplaceSubstring( @UpperCase(@Name([Abbreviate]; @ServerName));"\\"; "/" )
Gruss
Ray
IMHO hat das im Web nie funktioniert. Zumindest mit den Versionen 4 und 5 nicht.
Du kannst das aber so machen:
"/" + @ReplaceSubstring(@Subset(@dbName;-1); "\\";"/") + "/" + dieFormOderWasImmer.
Bei solchen relativen Links nimmt Domino immer den aktuellen Server und das ist in der Regel was du willst.
Es ist aber eigentlich eine schlechte Praxis den letztlich hartkodierten Servernamen irgendwo wie auch immer zu pflegen.
Ein solcher Link "/myApp.nsf/view1/doc3?openDocument" geht dank des ersten slashes immer gegen den Server, auf den er geklickt wird. Zur Verlinkung von Notesanwendung braucht es deshalb den Servernamen gar nicht.
Ich hab das in Domino Web Anwendungen immer so gemacht, dass es in allen Dokumenten, in denen Links erzeugt werden, ein Feld baseURL mit der Formel
"/" + @ReplaceSubstring(@Subset(@dbName;-1); "\\";"/") + "/"
gab. Da konnte man die Links auf Dokumente, Views, etc. easy drauf aufbauen.
Unnötige Konfigurationen (wie der hartkodierte Servername) besitzen ein hohes Risiko, doofe Arbeit, Verwirrung, etc. in der Zukunft zu erzeugen.