The entire 6.x codestream has seen some serious problems with views and documents appearing/disappearing, probably related to the new transaction-logging code. Hopefully all of this is finally fixed in 6.5.5:
SPR # JCHN6DRS62
Fixed in release:
6.5.5
Product Area: Server Technical Area: Database Platform: Cross Platform
SPR# JCHN6DRS62 - Fixed a problem where documents may intermittently not appear in the proper views. To cleanup any databases that may be in this state, you will need to run fixup -f -j followed by updall -R.
Anyway, here’s my question - I have a script that shows some serious issues with folder iteration that didn’t exist in R5. I’d like to see if 6.5.5 finally fixes things, but I can’t test 6.5.5 yet until the incremental installer comes out to due various other reasons. If somebody would like to test this out for me, here’s what you need to do:
Create a database with 3 documents
Put the 3 documents in a folder called “test”
Run this agent:
Sub Initialize
Dim s As New notessession
Dim db As notesdatabase
Dim v As notesview
Dim d As notesdocument
Dim i As Integer
Set db = s.currentdatabase
Set v = db.getview("test")
Set d = v.getfirstdocument
While Not (d Is Nothing)
i=i +1
Call d.RemoveFromFolder("test")
Set d= v.GetNextDocument(d)
Wend
Print i
End Sub
I just need to know what number is printed at the end of the agent. Yes, I know there is some questionable logic by calling a GetNextDocument() call using the context of a doc in a folder I just removed, but if somebody can let me know the result of this run it’d be a big help in knowing if I need to get this into Lotus Support’s hands.
Subject: RE: Could somebody with 6.5.5 test this simple script for me?
It does seem like a subtle bug there somewhere. If all you are intending to do is delete the contents of the folder though you could probably just change the script to this.
Sub Initialize
Dim s As New notessession
Dim db As notesdatabase
Dim v As notesview
Dim d As notesdocument
Dim dnext As notesdocument
Dim i As Integer
Set db = s.currentdatabase
Set v = db.getview("test")
Set d = v.getfirstdocument
While Not (d Is Nothing)
i=i +1
Call d.RemoveFromFolder("test")
Set d = v.getfirstdocument
Wend
Print i
Subject: RE: Could somebody with 6.5.5 test this simple script for me?
Thanks, but in the “real world” there would be some logic to determine whether or not to remove each doc. My code is just for demonstrative purposes of the document iteration being busted.
The behavior isn’t necessarily buggy yet, but what is weird is that AutoUpdate=False isn’t having an effect either way. It may only work in Views, but I (and Lotus Support) doubt that is the case. More research is underway.
Subject: RE: Could somebody with 6.5.5 test this simple script for me?
Thanks, Peter. I guess we’re breaking-in 6.5.5 together!
When I changed my logic to pre-fetch the next document before I remove the current one, I still get a result of 2 on 6.5.4:
Sub Initialize
Dim s As New notessession
Dim db As notesdatabase
Dim v As notesview
Dim d As notesdocument
Dim nextDoc as notesdocument
Dim i As Integer
Set db = s.currentdatabase
Set v = db.getview("test")
Set d = v.getfirstdocument
While Not (d Is Nothing)
Set nextDoc = v.GetNextDocument(d)
i=i +1
Call d.RemoveFromFolder("test")
Set d = nextDoc
Wend
Print i
End Sub
With the debugger on I can see that the last document in the folder is never hit. When processing the next-to-last doc on the red colored line above, nextDoc gets set to “Nothing”.
I tried adding a “v.AutoUpdated = False” line, but that didn’t help.
Can you try this in 6.5.5 and tell me what you get, or tell me what you changed in the logic to get a result of 3?
Subject: RE: Could somebody with 6.5.5 test this simple script for me?
Thanks Peter. That is the actual workaround I used – adding the docs to a temporary collection and then removing that from the folder.
I want to report this to Lotus Support, but I don’t want to bother them if it’s fixed in 6.5.5. Could you try the “nextdoc” assignment and see it still sees 2 docs? If that is broken in 6.5.5 then there’s definitely a problem.
Subject: RE: Could somebody with 6.5.5 test this simple script for me?
In my experience, the workaround is what you should do if you want it to work for a folder with a large number of documents. (Add to an empty Collection if you’re working with a subset.)
Take a folder with thousands of documents and compare removal per doc to all in a collection. The former grinds like coffee.
This was in 6.5.4, and I reckoned it was related to the folder architecture, so made a mental note on avoidance and moved on swiftly. If this is freak behaviour, I’d love to know
