@WebDBName Problem
Thought I'd pass on a bug/oddity/annoyance that I've uncovered in Domino recently.
There are some things that take me ages to learn. Like whether @WebDBName returns the leading forwards slash or not. It's not long ago that it finally stuck with me that it does not. Imagine my surprise then when a link I built using this function did have the slash and I ended up with a pair of them.
After a lot of head-scratching I worked out that the problem was domcfg.nsf. The problem only happens on Forms that are actually in your database, but which you've mapped to Domino using this configuration database. Things like login, error and change password forms.
Imagine you have a link you build like this:
"<a href=\"/" + @WebDBName+ "/person?OpenForm\">Create</a>"
The resulting HTML would be:
<a href="//dir/sub/db.nsf/person?OpenForm">Create</a>
As I'm sure you know, any link starting with a double // slash is treated as being outside the current site. The above link would try and find database /sub/db.nsf on a server call "dir". Most likely the user will end up with a timed-out network error.
Not only can this break links but also things like loading stylesheets and JavaScript libraries.
The reason I've not seen this sooner is that I tend to always use the Base HREF trick and so the links would like this:
http://server//dir/sub/db.nsf/person?OpenForm
In this case, most browsers simply treat the second double slash as a normal single one and there's no problem.
If you don't use that technique and you use the domcfg.nsf database then you either already are or probably should be aware of this behaviour.
To get round it you could compute your links like this:
path:=@WebDBName; @If(@Left(path;1)="/"; ""; "/") + path +"/person?OpenForm"
Personally, I'd always recommend using the Base HREF trick...
Skip to the 
You can subscribe to an individual
I always use the Base HREF trick too.
Usually like this:
"http://" + @Name([CN]; @ServerName) + "/" + @WebDbName
Jake,
Isn't it easier to use @ReplaceSubstring(URL ; "//" ; "/") instead of the @If statement.
Vitor
Jose. It's probably better to use the CGI field called Server_Name as this returns the server name of the URL being used. The @ServerName is a little less reliable and means the server needs to have the same name as the website it's hosting, which is not always possible.
Vitor. You're right. I don't use the code and just made it up on the spot. Yours is probably better.
I typically use the replicaid
"/__"+@replacesubstring(@Replicaid;":";"")+".nsf/"
This way I don't reveal the path of the DB. I store the value in a profile and store it in every document. Of course a maintenance view where my field dbURL and the ReplicaID don't match is needed.
:-) stw
Stephan,
(rant to follow) .. you store the base url in every document ???
Even though the replica id doesnt change across servers ... I can see why you need the maintenance view.
Dude, this sux. Just keep it dynamic.
I have seen this sort of thing before, (ie. keyword type of data on the document). Often in a field that is computed, where it should have been computed for display. It is often a pain and needs fixing.
cs.
In D6+, I'd use @GetHTTPHeader("Host") rather than Server_Name -- it saves a field and looks neater. Oh, and it returns server.domain.tld:port when the default (80) is not being used. That just leaves the protocol to deal with -- http VS https.
You could always fall back to the "old way" of doing it ...
WebDB_URL := @ReplaceSubstring( @Subset( @DbName ; -1 ) ; "\\":" " ; "/":"+" )
Same deal with that, Richard. You are still relying on the leading virgule/slash (the thing between the words "virgule" and "slash" back there a ways) to indicate that you want to use another URL on the same host using the same protocol. If domcfg.nsf adds another slash, the double slash is interpreted as "use the same protocol, but the new server name follows". It makes no difference whether you've used @WebDbName or the @ReplaceSubstring(@Subset(@DbName;-1);"\\":" ";"/":"%20") thing -- the result is the same.