Hi there,I’m using a profile-doc to give each new document a new (of course unique) sequential numer:
on QuerySave:
…
If source.IsNewDoc Then
Call seqNumber(source)
End If
…
sub seqNumber(source)
Dim profil As NotesDocument
Set profil = db.GetProfileDocument("Profil")
Dim seqNo As String
seqNo = Cstr(profil.seqNo(0))
profil.seqNo = profil.seqNo(0) + 1
Call profil.save(True, False)
exit sub
But now I encountered several documents with the same number - how can this happen??? And: these documents were created within 10 minutes(!!!), so a “buisy server” is unlikely to can be blamed for |-[
I have come across caching issues with profile documents before which have caused problems like these.
You update a field in a profile document yet when you go back to it the same value is there. However, if you close down your client and go back in the value has been updated. This caching issue doesn’t only apply to the UI - it also applies to the back end.
Nowadays I never use profile documents - I always create a view named “(Configs)” and create normal documents (as opposed to profiles) with a field named “ConfigName” in them which is displayed as the first sorted column of the view. I then create a function “GetConfigInfo()” which returns the config doc as a NotesDocument object.
A little more work than Profile documents - but at least you get correct values and no caching issues.
You can see the caching issues in effect sometimes if you edit your OOO profile (no need to enable the agent - just save & exit). When you go back in the old values are still there.
Hi Tom,nice idea, but for there are about 50 people who can create documents (and in this way also access the ConfigDoc) in that app: isn’t it quite likely to create conflict-documents? Or can I catch this case by checking the “LockHolders”-field?
Another way could be to count the total number of docs in a view (using EntryCount)…? But in this case I’d have to be sure that the view is up-to-date!
There are a few things you can to do reduce the possibility of a duplicate. One is to use some portion of the user’s name in the document key, and store that individual’s counter in their local notes.ini using an environment variable. Another is use a timestamp instead of a numeric increment.
Following is how I do it in an application that about 120 people update all day and I have never had an issue with conflicts. This generates a TicketNumber in the format YDDD-XXX, with Y being the year, DDD being the day of the year, then an incremental counter. There is only one document in the ($NumberWheel) view.
There is probably a more efficient way to handle this, and I welcome any suggestions to improve this or recommendations for another approach that would work better.
I have implemented sequential numbering in many notes apps and the easiest way is to do it on queryopen (and then have delete code in querysave if the user decides to not save).
Just create a hidden view sorted by your id (where ID <> “”), and use, call view.refresh and view.getlastdocuemt, this will give you the the most current id in the database, this avoids conflicts on the config doc or caching issues with profile docs.
Well, I already thought about using view.columncount in order to determine how many docs have been created so far, but I didn’t knew whether the view.refresh takes too long…?Here’s what I did (following Tom’s suggestion):
I created a view and a form “Counter”. The form holds one field containing the number.
When a user saves a new doc, following script is called:
[setting views, docs ‘n’ stuff]
For loopcount = 1 To 5
If Not counterdoc.LockHolders(0) = "" Then
Sleep(1)
Else
lockOK = counterdoc.Lock(s.effectiveUsername)
If lockOK Then
dummyNr = counterdoc.lfdNrGesamt(0)
counterdoc.lfdNrGesamt = dummyNr + 1
Call counterdoc.save(True,False)
Call counterdoc.UnLock
Exit For
End If
End If
Next
The Loop is for the case that there are several users trying to update the CounterDoc at the same time - or the server hangs
If the CounterDoc couldn’t be update within five tries, ID will be set to 0 and I’ll receive a mail…
Hope this will work! If not, I’ll give your idea a try!
Formula being generally faster than script you could achieve the same thing with @Subset(@DBColumn(“”:“NoCache”;@DBName;“view”;1);-1)
The only issue I have had with this is in databases with a large number of documents the view refreshes can have a significant performance impact on both the client and server.
But that’s not what profile documents were added for. If you want to share updates, just use normal documents.
Profile documents are used when your application needs to lookup static information over and over, and you don’t want to keep hitting the server for data that’s not changing.
