I’ve encountered a wierd problem with one of the applications at work. It’s a handbook application and a function that allows the user to submit feedback to the author of a certain handbook.
The problem occurs when the feedback is submited. The $$Return field contains the following code (it’s an older application so it has the long version of @WebDBName):
DBNAME := @LowerCase(@ReplaceSubstring(@Subset(@DbName ; -1) ; “\” ; “/”));
UNID := @Text(@DocumentUniqueID);
“[” + Server_Name + “/” + DBNAME+“/”+“0” + “/” + UNID + “?editDocument]”
After the submit the document should be presented to the user with a little “Thank you for your input” kind of message at the bottom. But instead of showing the document you get a “404 error - Entry not found in index” message.
After some debugging i noticed that @Text(@DocumentUNID) generates one value when you first open the form to create the document and another value after the document is submited. Why is this and what can i do to fix it?
Subject: @DocumentUNID switches value between display and submit
The UniversalID is NOT available until the document has been saved for the first time, and therefore You can’t use the @DocumentUniqueID when the document is newly created.
Is it really necessary to have the user to edit the document after submit?? If it’s only a matter of displaying a “Thank You”-message, I would place this text in a separate page/form and redirect the user there instead of back to the created document.
You have the option of supplying a link back to the created document by using CGI-variables (HTTP_REFERRER).
hth
Subject: RE: @DocumentUNID switches value between display and submit
oh, ok. Thanks for the quick awnsers 
Subject: @DocumentUNID switches value between display and submit
The “problem” has been discussed to death here (and in the R4 & R5 forum) and has to do with the fact that the UNID is basically a modified time stamp marking the creation of the Notes document, and since no Notes document exists until the document is saved in a web application, the value shown when the form is opened is not a valid UNID. But that shouldn’t be a problem here, since the UNID is regenerated before $$Return is recomputed – unless you are somehow locking in the value.