I am using the @Unique function to generate a unique key for documents in a web view. On the web I am using href=“content/key” to open the document.
I have now seen several times that keys which are identical except for the last letter involving V or W, Domino is returning the wrong document (the first in the view which is V). This is also happening using getdocumentbykey, with excact match set to True.
My latest keys that are generating this error are FH6Z4ULV and FH6Z4ULW.
Any suggestions ?
Subject: V and W ending in key not unique ?
FH6Z4ULV and FH6Z4ULW look unique to me. What difference if it is only the last letter? They are unique.
Subject: The wrong document are returned
When using the address href=“content/FH6Z4ULW” the document with key FH6Z4ULV is returned !
Subject: V and W ending in key not unique ?
Steinar, how are you creating the documents? From Notes or using the browser? How is the key field set?
How do you construct the links? Is the view up to date? Do both documents show in the view and if so, do both links point to the same document or does each one point to the wrong doc?
Can you confirm from a Notes client view that the keys are stored correctly in each document. If there are unique key stored in every document (no matter how they were created, Notes won’t remember that), GetDocumentByKey (exact match) should certainly NEVER mix up any of them. Bruce is a bit on a wrong track here, I’m afraid.
Subject: V and W ending in key not unique ?
From Notes Help
The following groups of @functions are not supported in Web applications or are supported differently than they are in Domino applications.
@Function Comments
@Certificate
@DbCommand Available only with the syntax @DbCommand(“Domino”;“ViewNextPage”) and @DbCommand (“Domino”;“ViewPreviousPage”) to create a link to the next/previous page in a view. Not available in other contexts.
@DDEExecute
@DDEInitiate
@DDEPoke
@DDETerminate
@DocMark
@DeleteDocument
@DocChildren
@DocDescendants
@DocLevel
@DocNumber
@DocParentNumber
@DocSiblings Not available except in column formulas.
@IsCategory
@IsExpandable
@Responses
@DialogBox
@PickList
@Prompt
@IsModalHelp
@GetPortsList
@Environment
@SetEnvironment
ENVIRONMENT keyword Use predefined field names to gather information about the Web user’s environment by requesting Common Gateway Interface (CGI) environment variables.
@MailSend
@Domain
@MailDbName
@MailEncryptSavedPreference
@MailEncryptSendPreference
@MailSavePreference
@MailSignPreference
@IsAgentEnabled
@IsDocBeingMailed
@Unique<<<<<<<
@URLGetHeader
@URLHistory
@UserPrivileges
@Platform for user’s platform. Returns server’s platform only. Use @ClientType to distinguish between Web and Domino users.
Subject: RE: V and W ending in key not unique ?
@Unique (without parameters) operates differently on the web in that the first four characters aren’t the current user’s “@Unique tag” (normally the firt character of the first name, followed by the first two and the last characters of the surname), but the “tag” of the code signer. That’s the only difference. Otherwise everything works as advertised (and there are a lot of Domino blog databases out there working just fine using @Unique to generate the permalink URL).
The problem in this case MAY be related to the server language settings, since it only involves keyed values where “V” and “W” are terminal characters – and “V” and “W” are essentially equivalent in some languages under some circumstances. This would also be a relatively rare occurence, since it depends on two specific characters and documents being created close enough to one another in time to get two successive @Unique time stamps. Might be worth a bug report.
Subject: RE: V and W ending in key not unique ?
I wonder whether, depending on the language of the server/client, the “Accent sensitive sorting” option of the column sort properties might make a difference.
Subject: RE: V and W ending in key not unique ?
I have been trying to modify the view settings, both the Accent sensitive sorting and the text language sort order in the View properties. The problem is still there. If I sort the View descending I have the same problem, but then returning the W document when it should return the one ending with V !