Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 467
  • Last Modified:

@Unique

I have a field which is Computed and set to @Unique.  However I seem to have ended up with two documents with the same 'unique' reference.  Does anyone know how this can happen?
0
fayeb
Asked:
fayeb
  • 5
  • 3
  • 2
  • +3
1 Solution
 
p_parthaCommented:
YOu mean @unique without parameters, It returns a random text value, although very rare, there might be a case where it repeats..

IN querysave you can do one more check (which may also fail) to see whether there are any other document with the same value or run a scheduled agent to check for duplicates and create new unique values

Partha
0
 
HemanthaKumarCommented:
This can rarely happen...In my experience I have never come across this problem !

Always make the field computed when composed.. so that it is not recomputed often.. which can raise a duplicates if there are other process triggered by same user which involves @unique

~Hemanth
0
 
CRAKCommented:
You've used a few words that set off a trigger here: "two documents" and "reference".
To avoid miscommunication: do you have two doc's, each with a double value, or two doc's sharing the same value?
@Unique won't be of any help to avoid the latter.

In the first scenario: I assume @Unique is applied in a translation formula. Does the field hold multiple values? And if so, if you look at the field in the documents properties: are they stored as text or as test lists?
If text lists: are the duplicate values (in the same field on the same document) true duplicates, or does one of the values perhaps have e.g. an additional space appended?

Any lotusscripts or agent adressing (writing) the field, bypassing the @unique fomula?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
RanjeetRainCommented:
There is a one-in-a-million chance of the value being duplicated.

Have you ever thought of using @Text(@UniqueDocumentID) instead?
0
 
RanjeetRainCommented:
Another line of thought would be to combine Hemantha and CRAK's suggestions.

Make your field a single value field and set the field type to CwC.
0
 
madheeswarCommented:
@Text(@UniqueDocumentID) has some problem.

When copy and paste a document, it has the same UNID stored in the field stored.  But in reality, the Doc id has been changed. So, u need to refresh the field in the doc manually or through code to get the new UNID of the doc.

If u make CWC and use @Text(@UniqueDocumentID), then u go into bigger problem. Even when refreshed, it won't change the value stored in the CWC field.
0
 
CRAKCommented:
Interesting, but strange. I've never seen that happen before. Only in cases where the doc id was stored in an additional field in effort to maintain "relational integrity".
In that case @Text(@UniqueDocumentID) isn't the problem, but (like you claim) the value stored in that field.
0
 
madheeswarCommented:
CRAK,
you are correct. when it comes to relational integrity between documents (consider a Unique Key), this problem arrises.

0
 
RanjeetRainCommented:
>> When copy and paste a document, it has the same UNID stored in the field stored. But in reality, the Doc id has been changed. So, u need to refresh the field in the doc manually or through code to get the new UNID of the doc

Releational Integrity was not a part of the original question and hence not important (IMO) wrt this question. If a person worries about relation integrity, he/she can always write a handler for the PostOpen event of the View. Trivial work.
0
 
RanjeetRainCommented:
Typo:

Such code handler should be written for POSTPASTE event.
0
 
fayebAuthor Commented:
I used @DocumentUniqueID to get around the problem.  I still do not understand why I have ended up with duplicate references using @unique.  The field was a single value computed field.  I don't need to worry about pasted documents as the application is web based only and copy and pasting is not allowed in the database.

'relational integrity' was the reason I needed the field to be unique as all the data gets exported into an access database.
0
 
CRAKCommented:
In situations where @DocumentUniqueID is NOT used, I guess copy/paste of documents, creation of documents at different locations (local + server, different servers etc.), simultaneous creation of documents and edit/save replication/save conflicts are the most common causes. Plenty of options!

Using @DocumentUniqueID (current situation) copy/paste and replication/save conflicts remain as probable cause for error. Not to mention any additional code to alter the field of course.

Using a computed field (instead of cwc), editing/saving a save conflict would recompute the field, providing a new unique value (cwc whould keep the original doc id).

The remaining copy/paste cause is ruled out bu Ranjeets suggestion to capture pastes.

Whatever caused it; you're much safer now!
0
 
RanjeetRainCommented:
Glad you resolved it!
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 3
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now